Comprendre les fuseaux horaires, UTC et les timestamps Unix

Le temps semble simple jusqu'à ce qu'on essaie d'écrire un logiciel qui le gère correctement. Un événement prévu à « 15 h » signifie des choses différentes à Tokyo, Londres et New York. L'heure d'été décale les horloges d'une heure — mais pas partout, et pas aux mêmes dates. Un timestamp qui semble correct dans votre environnement local plante en production parce que le serveur est dans un autre fuseau.

Les fuseaux horaires sont l'un des sujets les plus régulièrement déroutants en développement logiciel. Cet article explique comment ils fonctionnent, d'où vient la complexité, et comment éviter les erreurs les plus courantes.

Pourquoi les fuseaux horaires existent

La Terre tourne de 360 degrés en 24 heures, ce qui signifie que le soleil est au plus haut à des moments différents selon la longitude. Avant le XIXe siècle, chaque ville réglait ses horloges sur l'heure solaire locale — midi correspondait au moment où le soleil était au zénith. Cela fonctionnait jusqu'à ce que les chemins de fer relient des villes éloignées et qu'un horaire de train nécessite une horloge unique et cohérente.

En 1884, des délégués de 25 nations se sont réunis à la Conférence internationale du méridien à Washington et ont convenu de diviser le monde en 24 fuseaux horaires standard, chacun décalé par rapport au premier méridien (longitude 0°) passant par Greenwich, en Angleterre.

En pratique, les limites des fuseaux suivent les frontières politiques, pas de nettes lignes de longitude. La Chine s'étend sur cinq fuseaux géographiques mais utilise une seule heure officielle (UTC+8). L'Inde utilise UTC+5:30 — un décalage d'une demi-heure. Le Népal utilise UTC+5:45. La carte réelle des fuseaux horaires est désordonnée.

UTC vs. GMT

GMT (Greenwich Mean Time) est l'heure solaire moyenne à l'Observatoire royal de Greenwich. C'était la référence mondiale pendant plus d'un siècle.

UTC (Temps Universel Coordonné) a remplacé GMT comme standard international en 1972. UTC est basé sur des horloges atomiques plutôt que sur l'observation astronomique, ce qui le rend bien plus précis. Pour la plupart des usages pratiques, UTC et GMT affichent la même heure, mais UTC est la référence technique correcte.

L'heure d'été : le chaos organisé

Environ 70 pays observent le changement d'heure (DST), avançant les horloges d'une heure au printemps et les reculant en automne. L'objectif est d'aligner les heures d'éveil avec la lumière du jour. Le résultat est une source semestrielle de bugs.

Les complications principales :

• Pas universel. La majeure partie de l'Afrique, de l'Asie et de l'Amérique du Sud n'observe pas le changement d'heure. Aux États-Unis, l'Arizona et Hawaï ne le font pas.
• Des dates différentes. L'UE change le dernier dimanche de mars et d'octobre. Les États-Unis changent le deuxième dimanche de mars et le premier dimanche de novembre. Ils sont désynchronisés pendant plusieurs semaines chaque année.
• Heures ambiguës. Quand on recule les horloges, l'heure de 2 h à 3 h du matin se produit deux fois. Un timestamp de « 2 h 30 » ce jour-là est ambigu.
• Heures sautées. Quand on avance les horloges, l'heure de 2 h à 3 h du matin n'existe pas. Une réunion prévue à 2 h 30 ce jour-là n'arrive jamais.
• Changements politiques. Les gouvernements peuvent (et le font) modifier les règles du changement d'heure avec peu de préavis. La Russie a adopté l'heure d'été permanente en 2011, puis est passée à l'heure standard permanente en 2014. Le Maroc a modifié ses règles plusieurs fois.

ISO 8601 : le format de date universel

Pour éviter toute ambiguïté, le standard international ISO 8601 définit un format clair de date et d'heure :

2026-03-29T14:30:00Z
2026-03-29T14:30:00+02:00
2026-03-29T14:30:00-05:00

• Le T sépare la date de l'heure.
• Z signifie UTC (le fuseau « Zulu » en terminologie militaire).
• +02:00 ou -05:00 est le décalage par rapport à UTC.

Ce format est non ambigu, triable en tant que texte brut, et universellement compris par les bibliothèques d'analyse de dates. En cas de doute, utilisez ISO 8601.

Les timestamps Unix

Un timestamp Unix (aussi appelé epoch time ou temps POSIX) est le nombre de secondes écoulées depuis le 1er janvier 1970 à 00:00:00 UTC — un instant connu sous le nom d'époque Unix.

Les timestamps Unix n'ont pas de fuseau horaire — ils sont toujours en UTC. Cela les rend idéaux pour stocker et comparer des heures dans un logiciel. La conversion vers un fuseau local ne se fait qu'à la couche d'affichage.

La base de données IANA des fuseaux horaires

Les logiciels n'ont pas seulement besoin de décalages UTC — ils ont besoin de l'historique complet et des règles futures pour chaque région, y compris les transitions DST, les changements politiques et les anomalies historiques. Cette information vit dans la base de données IANA des fuseaux horaires (aussi appelée base Olson ou tzdata).

Elle utilise des identifiants comme America/New_York, Europe/Paris, Asia/Tokyo. Chaque entrée encode l'historique complet des décalages UTC et des règles DST pour ce lieu.

C'est pourquoi vous ne devez jamais stocker un fuseau horaire comme un décalage fixe tel que « +02:00 ». Un décalage indique la différence actuelle avec UTC mais ne dit rien sur les règles DST. Europe/Paris est UTC+1 en hiver et UTC+2 en été. L'identifiant IANA capture les deux.

Les bugs courants dans les logiciels

1. Stocker une heure locale sans fuseau. Une valeur comme 2026-03-29 14:30:00 est dénuée de sens sans savoir à quel fuseau elle se réfère. Stockez toujours en UTC ou incluez le décalage.
2. Confondre décalage UTC et fuseau horaire. UTC+2 en mars pourrait être UTC+3 en juillet (si la région observe le changement d'heure). Stockez l'identifiant IANA, pas le décalage.
3. Ignorer les transitions DST dans la planification. Une tâche quotidienne à 2 h 30 sera sautée une fois par an et exécutée deux fois une autre si vous ne gérez pas le changement d'heure.
4. Supposer que les jours font 24 heures. Les jours de changement d'heure font 23 ou 25 heures. Calculer « demain à la même heure » en ajoutant 86 400 secondes sera décalé d'une heure.
5. Utiliser Date en JavaScript naïvement. new Date("2026-03-29") est interprété comme UTC dans certains moteurs et comme heure locale dans d'autres. Soyez toujours explicite sur le fuseau.

Bonnes pratiques pour les développeurs

• Stockez les heures en UTC. Convertissez vers le fuseau local de l'utilisateur uniquement à la couche de présentation.
• Utilisez les identifiants IANA (America/New_York), pas les décalages fixes (-05:00).
• Utilisez ISO 8601 pour la sérialisation. C'est non ambigu et universellement analysable.
• Utilisez une bibliothèque de dates mature. En JavaScript, utilisez Intl.DateTimeFormat ou une bibliothèque comme date-fns-tz. En Python, utilisez zoneinfo (3.9+) ou pytz. En Java, utilisez java.time.ZonedDateTime.
• Gardez tzdata à jour. Les gouvernements changent les règles DST. Votre système d'exploitation et votre runtime ont besoin de données de fuseaux à jour.
• Testez avec plusieurs fuseaux. Ne supposez pas que votre serveur et vos utilisateurs partagent le même fuseau.

Pour aller plus loin

Le temps est d'une complexité trompeuse, mais les règles sont bien documentées et les outils sont matures. L'essentiel est de respecter la complexité plutôt que de la nier.

• Les expressions cron démystifiées — planifier des tâches à travers les fuseaux horaires
• Générateur de hash et Testeur de regex — d'autres outils pour développeurs sur ToolK