Une réunion s’affiche avec une heure de retard, une échéance est avancée à la veille ou une tâche récurrente ne correspond plus à l’horaire attendu. Ces erreurs ont souvent une cause commune : des notions temporelles différentes sont traitées comme si elles étaient équivalentes. Une politique de gestion des fuseaux horaires dans les applications doit définir ce que signifie chaque date, les informations à conserver et la façon de résoudre les situations ambiguës.
Il ne suffit pas de tout enregistrer en UTC ou d’afficher systématiquement l’heure de l’appareil. Le choix dépend de la nature de la donnée : représente-t-elle un événement ponctuel, une date de calendrier ou une règle qui doit se répéter à l’heure d’un lieu donné ? Voici une méthode pratique pour définir ces comportements et les tester avant qu’ils n’aient des conséquences pour les utilisateurs ou les opérations.
Distinguer les instants, les dates civiles et les heures locales
Un instant est un point unique sur la ligne du temps, identique pour tout le monde, même si chacun le voit affiché à une heure différente. L’enregistrement d’une transaction ou l’envoi d’une notification correspondent généralement à des instants. Ils peuvent être stockés sous forme d’horodatages normalisés en UTC, puis convertis pour l’affichage.
Une date civile est une date de calendrier, comme le 15 mai, sans heure ni fuseau horaire implicite. Une date de naissance, un jour férié ou la date limite de dépôt d’un formulaire peuvent avoir ce sens. La convertir en UTC peut changer le jour : elle ne doit donc pas être modélisée comme un instant si le besoin ne définit pas d’heure précise.
Une heure locale désigne une heure associée à un lieu, par exemple 9 h à Madrid. À elle seule, elle ne désigne pas un instant : la date et le fuseau horaire sont nécessaires, et certains changements saisonniers peuvent encore la rendre ambiguë. Dans le modèle produit, demandez-vous ce que la personne doit comprendre en lisant la donnée avant de choisir son type de stockage.
Que stocker : l’UTC, le fuseau IANA et la valeur d’origine
Pour un événement ponctuel déjà confirmé, stockez l’instant en UTC. Si le fuseau choisi est important pour expliquer la décision ou reconstituer l’expérience, conservez également le fuseau IANA, comme Europe/Paris, ainsi que, le cas échéant, la saisie locale d’origine. Un fuseau IANA identifie des règles régionales susceptibles d’évoluer ; il ne correspond pas à un décalage fixe tel que UTC+01:00.
Le décalage indique la différence par rapport à UTC à un moment donné. À lui seul, il ne contient ni les règles de changement saisonnier ni les futures évolutions légales. Ainsi, recevoir dans une API une date assortie d’un décalage peut suffire à identifier un instant, mais pas toujours à préserver l’intention « à 9 h à Madrid ». Dans ce cas, transmettez séparément l’instant et l’identifiant du fuseau.
Pour les dates civiles, utilisez un type ou un champ qui représente uniquement l’année, le mois et le jour. Pour une règle récurrente — par exemple, une réunion tous les lundis à 9 h dans un bureau — stockez l’heure locale, le fuseau IANA et la règle de récurrence. Ne transformez pas cette règle en une séquence permanente d’heures UTC : lorsque le décalage local change, la réunion risque de ne plus avoir lieu à 9 h pour les participants.
Définissez également la précision et les règles de validation. Précisez si les données acceptent les secondes ou les fractions de seconde, quels formats chaque API prend en charge et comment traiter les valeurs sans fuseau. Une valeur sans décalage ni fuseau peut être interprétée différemment par chaque système. Rejetez-la ou établissez une règle explicite au lieu de lui attribuer silencieusement le fuseau du serveur.
Afficher l’heure selon le contexte et l’intention
Pour un événement passé, il est souvent utile de l’afficher dans le fuseau de l’utilisateur, avec sa date et son heure locales. Pour une activité professionnelle liée à un établissement, l’heure de cet établissement peut être plus claire. Pour les réunions entre régions, envisagez d’afficher les deux fuseaux ou d’indiquer le lieu de référence. Le choix doit répondre à la question pratique de l’utilisateur : quand doit-il agir, et selon quelle horloge ?
Évitez les mentions vagues comme « heure locale » si l’on ne sait pas de qui il s’agit. Dans les confirmations et les avis importants, indiquez le fuseau ou le lieu avec suffisamment de contexte. Par exemple, un message au sujet d’un rendez-vous peut préciser l’heure convenue sur le lieu du rendez-vous et, si son destinataire se trouve dans une autre région, afficher également l’équivalent. Vérifiez que la conversion est effectuée au bon moment, plutôt qu’avec un décalage fixe repris d’une ancienne configuration.
Les préférences de l’utilisateur et les règles métier ne coïncident pas toujours. Un utilisateur peut vouloir consulter toutes les activités dans son fuseau, tandis qu’une échéance légale doit respecter la date et le fuseau définis par l’organisation. Rendez cette priorité explicite dans l’interface et la logique : modifier les paramètres d’affichage ne doit pas changer silencieusement la date limite officielle.
Gérer les échéances, les rendez-vous et les changements saisonniers
Avant de programmer une échéance, déterminez si elle correspond à un instant ou à la fin d’une journée civile. « Jusqu’au 15 mai » peut signifier que la journée entière est incluse dans un fuseau précis, et non que le délai expire à minuit UTC au début de cette journée. Documentez le fuseau qui régit l’échéance, le caractère inclusif ou exclusif de la limite et le comportement de l’interface.
Les changements saisonniers créent deux situations distinctes qu’il faut traiter séparément. Une heure peut ne pas exister lorsque les horloges avancent ; une autre peut se produire deux fois lorsqu’elles reculent. Pour un rendez-vous saisi à une heure inexistante, le produit doit soit le refuser en l’expliquant, soit appliquer une règle convenue, comme le déplacer à la prochaine heure valide. Pour une heure qui se répète, il doit demander laquelle des deux occurrences est souhaitée ou choisir une politique sans ambiguïté et la communiquer.
Pour les tâches récurrentes, conservez la règle en heure locale et calculez chaque prochaine occurrence en fonction des règles du fuseau. Déterminez ce qui se passe si le fuseau change, si une date d’exécution tombe un jour non ouvré ou si l’heure prévue n’existe pas. À l’inverse, une tâche qui doit s’exécuter à intervalles réels réguliers — par exemple toutes les 24 heures après un instant de départ — diffère d’une tâche qui doit s’exécuter chaque jour à la même heure du calendrier.
Éviter les divergences entre les API, les bases de données et les systèmes
Une intégration peut compromettre une politique correcte si chaque composant interprète les champs différemment. Définissez des contrats qui précisent le format, le fuseau, la précision et la sémantique. Un champ nommé created_at devrait représenter un instant ; un champ comme due_date pourrait correspondre à une date civile, mais son nom ne suffit pas : la documentation doit le préciser.
Vérifiez que les couches de présentation ne modifient pas la donnée d’origine et que les systèmes externes ne suppriment pas le fuseau IANA lors de l’importation d’un rendez-vous. Examinez également les files d’attente, les exports, les rapports et les journaux : un rapport regroupé par jour UTC peut afficher des totaux différents d’un rapport regroupé selon le jour local d’un établissement. Aucun de ces regroupements n’est automatiquement erroné, mais il doit répondre à la question métier visée.
Les règles de fuseau peuvent évoluer à la suite de décisions administratives. Pour les calculs futurs, utilisez les règles en vigueur au moment du calcul et prévoyez qu’une mise à jour peut modifier les conversions à venir. À des fins d’audit, conservez suffisamment d’informations pour expliquer quelle valeur l’utilisateur a reçue et quel fuseau a été appliqué. Ne supposez pas qu’un horodatage suffit à documenter l’intention initiale associée à un rendez-vous.
Tests et liste de contrôle pour une politique commune
Les tests doivent couvrir davantage que les conversions courantes. Incluez des dates proches des changements d’heure, des fuseaux avec et sans changement saisonnier, des utilisateurs et des entreprises situés dans des régions différentes, des dates civiles et des données historiques. Vérifiez à la fois la valeur stockée et ce qui apparaît dans les écrans, les messages, les rapports et les systèmes intégrés.
- Classez la donnée : instant, date civile, heure locale avec fuseau ou règle récurrente.
- Définissez la référence faisant autorité : fuseau de l’utilisateur, établissement, juridiction ou configuration de l’événement.
- Établissez des règles explicites : saisies ambiguës, heures inexistantes, limites d’échéance et valeurs sans fuseau.
- Documentez le contrat : formats, précision, champs et conversion attendue pour chaque API.
- Testez les cas limites : changement saisonnier, changement de jour, fuseaux différents, mise à jour des règles et nouvelles tentatives.
- Vérifiez les communications : assurez-vous que chacun comprend quand agir et quel fuseau régit l’échéance.
Une bonne politique temporelle transforme les décisions implicites en règles visibles. Stockez les instants comme des instants, les dates de calendrier comme des dates et les récurrences locales avec leur fuseau. Vérifiez ensuite que les équipes produit, opérations et intégration partagent la même interprétation. Vous réduirez ainsi les décalages inattendus et pourrez expliquer plus facilement chaque date lorsqu’une divergence survient.