Migrer les dates locales vers UTC en PHP ne consiste pas simplement à changer le fuseau horaire du serveur ni à soustraire un nombre fixe d’heures. Avant de modifier les données, il faut déterminer ce que signifie chaque valeur, dans quel fuseau elle était interprétée et si elle désigne un instant précis ou une règle civile. Si ces réponses ne sont pas claires, une conversion automatique peut rendre les données plus uniformes, sans pour autant les rendre correctes.
La stratégie la plus sûre est progressive : inventorier les données, définir une politique pour chaque type de donnée, ajouter un nouveau champ, convertir et vérifier par lots, puis maintenir la compatibilité en lecture et en écriture pendant toute la transition. L’interface peut continuer à afficher les heures habituelles, même si le stockage représente désormais les instants de manière cohérente.
Diagnostiquer les dates et les dépendances actuelles
Commencez par localiser toutes les sources de date et d’heure : colonnes de base de données, fichiers d’importation, files d’attente, intégrations API et valeurs générées en PHP. Examinez les types et les conventions : une colonne DATETIME stocke généralement des composantes de date et d’heure sans conserver, à elle seule, le fuseau horaire. Un TIMESTAMP peut faire l’objet de conversions de fuseau dépendant du moteur et de la session. Ne déduisez pas sa signification uniquement du nom du type.
Recherchez également les formats mixtes. Certains enregistrements peuvent, par exemple, représenter une heure locale, d’autres UTC, et d’autres encore avoir été importés depuis une source dont le fuseau est inconnu. Comparez des échantillons avec des événements externes, l’historique d’audit ou les règles métier. Vérifiez la configuration de PHP, le fuseau de la connexion à la base de données et les appels à date() ou strtotime() qui dépendent du fuseau par défaut.
Le fait qu’une même valeur s’affiche différemment selon le serveur ou le processus qui la lit constitue un signal de risque. Un autre indice est un décalage horaire constant qui varie selon la période de l’année : cela peut indiquer que l’heure locale et UTC sont mélangées et que le changement d’heure saisonnier entre en jeu.
Distinguer les instants, les dates civiles et les horaires récurrents
Un instant est un point unique sur la ligne du temps, comme le moment où un paiement a été confirmé. Il peut être normalisé et stocké en UTC ; le fuseau de présentation est appliqué à l’affichage. En PHP, DateTimeImmutable associé à DateTimeZone permet d’exprimer explicitement le fuseau d’origine et de convertir le résultat :
$local = new DateTimeImmutable($valor, new DateTimeZone('Europe/Madrid'));
$utc = $local->setTimezone(new DateTimeZone('UTC'));Cet exemple n’est valable que si la date et l’heure d’entrée ont été vérifiées et représentent un instant non ambigu. Le constructeur peut normaliser silencieusement une heure locale inexistante lors du changement d’heure et, lorsqu’une heure se répète, choisir l’une des occurrences sans que l’entrée le précise. Avant la persistance, vérifiez que l’heure existe et appliquez une politique explicite pour les répétitions : par exemple, résolvez-les à l’aide d’un décalage ou d’éléments attestant l’origine, ou signalez l’enregistrement pour révision. Si vous ne pouvez pas déterminer l’instant de manière fiable, conservez la valeur comme donnée civile ou laissez-la en attente ; ne considérez pas la conversion comme valide simplement parce que PHP a renvoyé un objet.
Une date civile, en revanche, peut être « le 14 avril », sans heure ni fuseau. Un anniversaire ou une échéance définie par le calendrier ne doit pas être converti en instant UTC si le métier ne lui attribue pas d’heure précise : cela pourrait changer le jour lors de l’affichage dans un autre fuseau.
Un horaire récurrent, comme « la réunion a lieu tous les lundis à 9 h à Madrid », exprime une règle dans un fuseau civil. Cela ne revient pas à répéter le même instant UTC chaque semaine, car le décalage du fuseau peut changer. Conservez l’heure locale, le fuseau IANA et la règle de récurrence ; calculez les prochains instants selon ces conditions.
Retrouver le sens historique avant la conversion
Pour convertir une date locale, vous devez connaître le fuseau applicable au moment de son enregistrement. Il ne suffit pas d’utiliser le fuseau actuel de l’utilisateur ou la configuration actuelle du serveur. L’application a peut-être fonctionné dans un seul fuseau, ou les données peuvent provenir de différentes agences. Recherchez des éléments dans la configuration historique, l’origine de l’enregistrement, le compte associé et les règles alors en vigueur.
Certaines heures locales ne désignent pas un instant unique. Lorsque l’horloge recule, une heure peut se produire deux fois ; lorsqu’elle avance, certaines heures n’existent pas. Il peut également y avoir des valeurs incomplètes, comme une heure sans date ou une date importée sans fuseau. Ne les convertissez pas silencieusement en appliquant une hypothèse générale : classez-les comme ambiguës, inexistantes ou sans origine vérifiable, puis définissez une politique avec l’équipe responsable.
Selon le cas, la politique peut exiger de choisir l’une des occurrences à partir d’éléments externes, de conserver la valeur d’origine comme donnée civile ou de laisser l’enregistrement en attente de révision. Documentez la décision et stockez le fuseau IANA, par exemple Europe/Madrid, et non seulement une abréviation comme « CET », dont la signification peut ne pas suffire à reconstituer les règles historiques.
Concevoir une migration progressive et compatible
Évitez d’écraser immédiatement l’unique colonne disponible. Ajoutez un nouveau champ pour l’instant normalisé et, si le domaine en a besoin, un autre pour le fuseau ou l’heure civile d’origine. Définissez ce que représente chaque champ dans le schéma et dans le code ; un nom comme starts_at_utc peut aider, à condition que l’application respecte cette convention de manière cohérente.
Pendant la période de coexistence, convenez d’une source unique de vérité pour les écritures. La double écriture peut faciliter la transition, mais elle risque de faire diverger les champs si une opération met à jour l’un sans mettre à jour l’autre. Centralisez cette logique dans un chemin d’écriture, utilisez des transactions lorsque cela est approprié et consignez les échecs. Pour les lectures, définissez une priorité explicite : utiliser le nouveau champ lorsqu’il est disponible et recourir à l’ancien uniquement pour les enregistrements qui n’ont pas encore été migrés.
Limitez la période de coexistence et définissez comment en mesurer l’avancement. Avant de planifier son retrait, vérifiez quelles applications, quels rapports, quelles exportations et quels consommateurs d’API lisent encore l’ancien champ. Maintenir la compatibilité ne signifie pas conserver indéfiniment deux interprétations.
Convertir par lots et vérifier la transformation
Traitez les enregistrements par lots de taille limitée, avec des critères de sélection stables et un marqueur permettant de reprendre le travail. La conversion doit pouvoir être répétée : si un lot est exécuté à nouveau, une date déjà convertie ne doit pas être décalée une seconde fois. Conservez la valeur d’origine pendant la phase de validation et consignez l’identifiant, le fuseau supposé, le résultat et toute exception, en évitant d’inclure des données personnelles inutiles dans les journaux techniques.
Avant de mettre à jour un lot, calculez un aperçu et examinez des cas représentatifs. Comparez ensuite les décomptes, les valeurs avant et après, les enregistrements nuls et la répartition des erreurs. Vérifiez également les propriétés métier : par exemple, qu’une réservation reste associée à la date civile attendue dans son fuseau métier. Un décalage horaire peut être correct pour un instant tout en révélant une erreur si le jour d’une date qui devait rester civile a changé.
Arrêtez le processus si les exceptions dépassent le seuil convenu ou si des valeurs sans origine claire apparaissent. Corrigez la règle ou isolez ces enregistrements pour révision ; ne les forcez pas à suivre la même conversion que les cas vérifiables.
Adapter la saisie, la lecture et les tests
À la réception des données, interprétez la date dans le fuseau correspondant à l’utilisateur ou au métier, puis validez le format attendu. Convertissez un instant en UTC lors de sa persistance, une fois que la saisie a passé les contrôles d’existence et d’ambiguïté définis pour ce fuseau. À la sortie, convertissez cet instant dans le fuseau de présentation approprié. Pour les API, convenez d’un format non ambigu, comme un horodatage accompagné d’un indicateur de fuseau, et documentez si les champs représentent des instants ou des valeurs civiles.
Les tests doivent inclure des fuseaux explicites et des cas autour des changements d’heure saisonniers : heures inexistantes et répétées, minuit, limites de journée et conversions entre fuseaux. Ajoutez des tests aller-retour : interpréter une entrée, enregistrer l’instant, l’afficher à nouveau dans le fuseau d’origine et vérifier que le sens attendu est préservé. N’exigez pas que la chaîne de caractères soit toujours identique si la sortie est normalisée ; vérifiez les composantes et la sémantique. Ajoutez également des tests confirmant qu’une heure inexistante est rejetée ou traitée conformément à la politique, et qu’une heure répétée n’est pas résolue sans appliquer la règle prévue.
Liste de contrôle avant le retrait de l’ancien champ
- Chaque champ a été classé comme instant, date civile ou règle récurrente.
- Le fuseau d’origine est documenté et les cas ambigus font l’objet d’une politique explicite.
- Les nouvelles écritures respectent une source de vérité unique et les lectures compatibles ont une date de retrait.
- La conversion par lots peut être reprise et assure la traçabilité des exceptions.
- Les tests couvrent les changements d’heure, les limites de journée, les API et l’affichage dans différents fuseaux.
- Les rapports, les exportations, les tâches planifiées et les intégrations ne dépendent plus de l’ancien champ.
Ne retirez l’ancien champ que lorsque la migration a été validée et qu’il ne reste aucun consommateur dépendant de son interprétation. Stocker les instants en UTC, utiliser les fuseaux IANA pour les règles civiles et donner une sémantique claire à chaque champ réduit les ambiguïtés sans obliger l’interface à exposer les détails internes du stockage.
