Les dates sont une source classique de bugs subtils en programmation (pas seulement en PHP), à cause des fuseaux horaires, des formats et de la complexité intrinsèque du temps — voici les pièges principaux et comment les éviter. (1) Le FUSEAU HORAIRE mal configuré. LE piège n°1. Si le fuseau horaire n'est pas correctement défini (dans la configuration PHP ou explicitement), les dates/heures peuvent être DÉCALÉES (par exemple, le serveur est configuré sur un fuseau différent du vôtre, et toutes vos heures sont fausses de plusieurs heures). Conséquences : des horodatages incorrects, des calculs de durée faux, des affichages trompeurs. Comment éviter : (a) CONFIGUREZ explicitement le fuseau horaire (dans php.ini via date.timezone, ou dans le code via date_default_timezone_set()) — utilisez le bon fuseau pour votre contexte. (b) Pour les applications INTERNATIONALES, stockez les dates en UTC (temps universel) et convertissez au fuseau de l'utilisateur seulement à l'affichage — c'est la pratique recommandée pour gérer plusieurs fuseaux. (c) Avec DateTime, vous pouvez spécifier le fuseau explicitement, ce qui donne le contrôle. (2) Confondre FORMAT de STOCKAGE et FORMAT d'AFFICHAGE. Un piège fréquent : stocker les dates dans un format d'affichage LOCALISÉ (comme « 25/07/2026 » ou « July 25, 2026 »). C'est une ERREUR. Il faut STOCKER les dates dans un format STANDARD, non ambigu, triable (typiquement le format ISO AAAA-MM-JJ HH:MM:SS, qui est aussi le format des dates en base de données), et FORMATER pour l'affichage SEULEMENT au moment de montrer à l'utilisateur (->format('d/m/Y')). Pourquoi : (a) le format ISO est NON AMBIGU (25/07 vs 07/25 — jour/mois ou mois/jour ? l'ISO AAAA-MM-JJ lève l'ambiguïté) ; (b) il est TRIABLE (les dates ISO se trient correctement comme des chaînes) ; (c) il est standard (bases de données, échanges). Stocker un format localisé rend les dates difficiles à trier, comparer, et sujettes aux ambiguïtés. Règle : stockage en ISO/standard, affichage formaté/localisé. (3) Utiliser les fonctions ANCIENNES vs DateTime. Les fonctions procédurales anciennes (date(), strtotime(), mktime()) fonctionnent mais sont moins pratiques et plus piégeuses pour les manipulations complexes (calculs, différences, fuseaux). PHP moderne privilégie la classe DateTime (et surtout DateTimeImmutable, non modifiable — plus sûr, évite des bugs de modification accidentelle) : plus lisible, plus puissante (différences avec diff, ajout/soustraction d'intervalles, gestion des fuseaux). Utilisez DateTime/DateTimeImmutable pour les manipulations de dates. (4) Les calculs de DURÉE et d'INTERVALLE. Calculer une différence entre deux dates « à la main » (soustraire des timestamps) est piégeux (années bissextiles, changements d'heure, mois de longueurs différentes). Utilisez ->diff() de DateTime qui gère cela correctement (renvoie un intervalle avec années, mois, jours…). (5) Le CHANGEMENT D'HEURE (heure d'été/hiver). Les transitions d'heure (DST) causent des bugs subtils (une journée peut avoir 23 ou 25 heures, une heure peut « ne pas exister » ou « exister deux fois »). DateTime avec les bons fuseaux gère cela ; les calculs manuels sur timestamps peuvent se tromper. (6) Les FORMATS d'ENTRÉE. Parser une date depuis une chaîne (saisie utilisateur, format inconnu) est risqué (strtotime peut mal interpréter). Utilisez DateTime::createFromFormat() pour parser un format PRÉCIS et connu, et validez. Les bonnes pratiques résumées : (1) CONFIGUREZ le fuseau horaire explicitement ; pour l'international, stockez en UTC, affichez au fuseau de l'utilisateur. (2) STOCKEZ les dates au format STANDARD ISO (AAAA-MM-JJ), FORMATEZ seulement à l'affichage (ne jamais stocker un format localisé). (3) Utilisez DateTime/DateTimeImmutable (moderne, puissant) plutôt que les fonctions anciennes pour les manipulations. (4) Utilisez ->diff() pour les différences (gère bissextiles, mois, etc.). (5) Parsez les entrées avec createFromFormat (format précis) et validez. En résumé : les pièges des dates en PHP sont surtout le FUSEAU HORAIRE mal configuré (heures fausses — piège n°1, à configurer explicitement, UTC pour l'international), la confusion FORMAT DE STOCKAGE (ISO standard) / AFFICHAGE (localisé, seulement au moment de montrer), l'usage des fonctions anciennes plutôt que DateTime, et les calculs de durée/DST manuels. Les éviter : configurez le fuseau, stockez en ISO et formatez à l'affichage, utilisez DateTime/DateTimeImmutable et ses méthodes (diff, format). Les dates sont intrinsèquement complexes (fuseaux, formats, calendrier) — s'appuyer sur les outils appropriés (DateTime) et suivre ces bonnes pratiques évite des bugs subtils et fréquents. Une gestion rigoureuse des dates est un marqueur de code soigné.

Les expressions régulières (regex) sont un outil PUISSANT mais souvent MAL UTILISÉ — il vaut la peine d'en comprendre les bases, mais il faut savoir quand les utiliser et surtout quand les ÉVITER au profit d'outils plus adaptés. Ce que sont les regex : un mini-langage pour décrire des MOTIFS dans du texte, permettant de VÉRIFIER (une chaîne correspond-elle à un format ?), EXTRAIRE (récupérer des parties), REMPLACER (selon un motif), DÉCOUPER. En PHP : preg_match, preg_match_all, preg_replace, preg_split. Leur réputation (méritée) : les regex sont à la fois puissantes et DIFFICILES. Leur syntaxe est cryptique (/^[a-z0-9._%+-]+@.../), difficile à lire, à écrire correctement, et à déboguer. Une regex mal écrite peut ne pas couvrir tous les cas, en accepter de mauvais, ou même causer des problèmes de performance (certaines regex mal formées sont très lentes sur certaines entrées — un risque de déni de service). D'où la prudence recommandée. Quand ÉVITER les regex (au profit d'autres outils) : (1) Pour les VALIDATIONS COURANTES (email, URL, IP, entier…). C'est le conseil le plus important : n'écrivez PAS votre propre regex pour valider un email, une URL, etc. Utilisez filter_var() avec les filtres appropriés (FILTER_VALIDATE_EMAIL, FILTER_VALIDATE_URL, FILTER_VALIDATE_INT…). Pourquoi : valider un email CORRECTEMENT par regex est étonnamment DIFFICILE (la spécification des emails valides est complexe) — les regex « maison » d'email sont presque toujours soit trop strictes (rejettent des emails valides) soit trop laxistes (acceptent des invalides). filter_var le fait de façon éprouvée et fiable. Idem pour les URL, IP, etc. Ne réinventez pas ces validations par regex. (2) Pour des manipulations SIMPLES de chaînes (chercher une sous-chaîne, remplacer un mot exact, découper sur un séparateur) : utilisez les fonctions de chaîne dédiées (str_contains, str_replace, explode…) plutôt qu'une regex — plus simples, plus lisibles, plus rapides. On voit parfois des regex utilisées pour des tâches triviales que des fonctions de chaîne feraient mieux (« utiliser un marteau-piqueur pour planter un clou »). Quand les regex sont JUSTIFIÉES : (1) Pour des motifs SPÉCIFIQUES à votre besoin, non couverts par les outils standard : valider un format particulier (un code produit interne, un format de référence spécifique, un numéro selon une règle métier), extraire des données selon un motif précis d'un texte, faire un remplacement conditionnel complexe. (2) Quand le motif est réellement « à motif » (une structure qui se décrit bien par un pattern, avec des variations) et qu'aucune fonction dédiée ne le fait. Dans ces cas, les regex sont l'outil adapté et puissant. Faut-il les APPRENDRE ? Oui, il vaut la peine de comprendre les BASES des regex (les métacaractères courants, comment lire et écrire des motifs simples), car : (1) vous en RENCONTREREZ (dans du code existant, des configurations, des outils) — savoir les lire est utile ; (2) elles sont parfois le bon outil (motifs spécifiques) ; (3) elles sont TRANSVERSALES (les regex existent dans presque tous les langages et outils — un savoir réutilisable). Mais n'en faites pas une obsession : (1) apprenez à LIRE et écrire des regex SIMPLES ; (2) pour les cas complexes, appuyez-vous sur des ressources (des outils en ligne de test/explication de regex existent, très utiles pour construire et comprendre une regex) ; (3) utilisez les outils DÉDIÉS (filter_var, fonctions de chaîne) quand ils existent, plutôt que des regex ; (4) TESTEZ soigneusement vos regex (avec des cas variés, y compris limites) — une regex non testée est risquée. Conseils pratiques : (1) pour valider email/URL/etc. → filter_var (pas de regex maison). (2) Pour chercher/remplacer/découper simplement → fonctions de chaîne. (3) Pour des motifs SPÉCIFIQUES → regex, testées, avec l'aide d'outils. (4) COMMENTEZ vos regex complexes (expliquez ce que fait le motif) — sans commentaire, une regex est illisible six mois plus tard. En résumé : oui, comprenez les bases des regex (utile, transversal, parfois le bon outil), mais utilisez-les à BON ESCIENT : ÉVITEZ-les pour les validations courantes (email, URL → filter_var, plus fiable qu'une regex maison) et les manipulations simples (→ fonctions de chaîne) ; RÉSERVEZ-les aux motifs spécifiques non couverts par les outils standard. Les regex sont puissantes mais difficiles et souvent mal utilisées — le bon développeur sait quand les employer (motifs spécifiques, testées, commentées) et quand préférer un outil dédié (le cas le plus fréquent). Ne tombez pas dans le piège d'utiliser des regex partout par « virtuosité » : le bon outil pour le bon besoin, et pour beaucoup de cas courants, ce n'est PAS une regex.