Qu'est-ce que la base de données de fuseaux horaires IANA (et pourquoi elle compte)

Quand votre ordinateur portable recule discrètement d'une heure un dimanche matin, ou qu'une invitation d'agenda envoyée par un collègue de São Paulo arrive exactement au moment où vous l'attendiez, c'est le même rouage invisible qui a fait le travail : un jeu de données librement maintenu que presque tous les systèmes d'exploitation, langages de programmation et services web considèrent comme l'autorité en matière d'heure civile. Il s'agit de la base de données de fuseaux horaires IANA — aussi appelée base tz, tzdata, ou historiquement base Olson, du nom d'Arthur David Olson, qui a commencé à la maintenir dans les années 1980.

Les fuseaux horaires donnent l'impression de relever de la géographie, mais ils relèvent de la politique. Un gouvernement peut décider de mettre fin au passage à l'heure d'été plus tôt, de modifier son décalage standard, ou de sauter un jour entier — parfois avec seulement quelques semaines de préavis. La base tz est le référentiel commun qui absorbe ces changements, de sorte que la question « quelle heure est-il à Londres quand il est 15 h à New York ? » ait partout une réponse cohérente. Cet article explique ce que contient réellement cette base, comment une mise à jour passe d'un décret gouvernemental à votre téléphone, et pourquoi le raccourci tentant qui consiste à stocker un décalage fixe comme « UTC+1 » est un bug en puissance.

Ce qu'est réellement la base de données

La base tz est un ensemble de fichiers en texte brut décrivant les règles de l'heure locale à travers le monde — aujourd'hui comme aussi loin dans le passé que les archives le permettent raisonnablement. On ne l'exécute pas ; ce sont les logiciels qui la lisent. N'importe qui peut la télécharger, et les données ne sont assorties d'aucune restriction de licence, ce qui explique en partie pourquoi elle s'est retrouvée partout.

Chaque région est identifiée par un nom de zone sous la forme `Zone/Lieu` : `America/New_York`, `Europe/London`, `Asia/Kolkata`, `Australia/Lord_Howe`. Le lieu est généralement une ville représentative, et non un pays, et c'est délibéré. Un même pays peut être soumis à plusieurs jeux de règles, et les noms de villes sont bien plus stables au fil des décennies que les frontières ou les noms de pays. La base définit quelques centaines de ces zones.

Pour chaque zone, les données enregistrent :

• Le décalage de base par rapport à UTC — par exemple, `America/New_York` est en UTC−5 l'hiver (EST).
• Les règles de passage à l'heure d'été en vigueur, y compris le moment exact où elles commencent et se terminent chaque année.
• Les transitions historiques — chaque changement passé du décalage ou de la règle DST de cette zone.
• Les abréviations en usage à chaque période, telles que EST, EDT, CET ou IST.

Cette dimension historique est ce qui distingue tzdata d'une simple table de décalages. Elle ne sait pas seulement que New York est en UTC−5 aujourd'hui. Elle sait que les États-Unis ont avancé la date de début de leur DST à partir de 2007, et elle applique la règle correcte selon la date que vous demandez. C'est pourquoi un convertisseur bien conçu peut vous indiquer le décalage pour une date de 1995 avec autant d'assurance que pour mardi prochain.

Zones, liens et les déroutantes entrées « Etc »

La base définit également des liens — des alias qui font pointer un nom vers un autre, afin que les renommages ne cassent pas les systèmes existants. Lorsque la zone de l'Inde s'est fixée sur `Asia/Kolkata`, l'ancien `Asia/Calcutta` a été conservé comme lien vers celui-ci. Les deux correspondent toujours à UTC+5:30.

Il existe aussi des zones `Etc/` pour les décalages fixes, dont `Etc/UTC` et le fameux `Etc/GMT+5` à l'envers. Celui-ci correspond à UTC−5, et non à UTC+5 : les noms `Etc/GMT±` inversent le signe selon une vieille convention POSIX. Ces zones à décalage fixe existent pour des besoins techniques de niche. Pour tout endroit où vivent de vraies personnes, il vous faut une zone géographique — car seule une zone géographique tient compte du passage à l'heure d'été et des futurs changements de règles. La section suivante explique pourquoi cela compte.

Pourquoi les règles de fuseaux horaires changent si souvent

Les gens supposent que les fuseaux horaires sont figés. Ils ne le sont pas. La base tz est mise à jour plusieurs fois au cours d'une année typique, parfois davantage. Les versions sont numérotées par année suivie d'une lettre — `2023a`, `2023b`, `2024a` — et chacune regroupe l'ensemble des changements de règles et des corrections accumulés depuis la précédente.

Ces changements proviennent d'une poignée de sources récurrentes :

• Des gouvernements modifiant leur politique de DST. Un pays commence à observer l'heure d'été, l'abandonne, ou déplace les dates de transition. L'Union européenne débat depuis des années de la suppression du changement d'heure saisonnier, et plusieurs États américains ont adopté des lois réclamant une DST permanente, en attente d'une approbation fédérale.
• Des changements de décalage purs et simples. Il arrive qu'un territoire adopte entièrement une heure standard différente. Le cas d'école : fin 2011, les Samoa ont sauté le 30 décembre purement et simplement, passant de l'autre côté de la ligne de changement de date pour aligner leur semaine de travail sur l'Australie et la Nouvelle-Zélande plutôt que sur la côte ouest des États-Unis.
• Des annonces de dernière minute. C'est la partie difficile. Un gouvernement annonce parfois un changement quelques semaines — voire quelques jours — avant son entrée en vigueur. Les mainteneurs et les fournisseurs en aval s'empressent alors de publier et de distribuer une mise à jour avant la date fatidique.
• Des corrections historiques. Des chercheurs exhument de vieux textes de loi, des archives de journaux ou des horaires de chemin de fer qui précisent ce qu'*était* le décalage d'une zone il y a des décennies, et ces corrections sont également intégrées.

La conclusion sans détour : la règle d'un lieu n'est connue que jusqu'à la prochaine décision gouvernementale. Tout système qui suppose que les règles d'aujourd'hui sont permanentes finira par se tromper.

Comment une mise à jour parvient jusqu'à votre téléphone

La base est maintenue par une communauté de bénévoles qui se coordonnent sur une liste de diffusion publique, l'IANA (Internet Assigned Numbers Authority) jouant le rôle de point d'hébergement et de distribution officiel. Un changement suit généralement ce parcours :

1. Quelqu'un le signale sur la liste de diffusion tz, en citant le plus souvent un journal officiel, une annonce officielle ou des recherches sur sources primaires. 2. Les mainteneurs le vérifient et en discutent, puis intègrent la modification au fichier de données concerné. 3. L'IANA publie une nouvelle version assortie d'une étiquette telle que `2024a`. 4. Les consommateurs en aval l'intègrent — distributions Linux, macOS, environnements d'exécution des langages et grandes plateformes. (Windows conserve son propre format de fuseaux horaires et établit une correspondance avec les noms IANA.) 5. Votre appareil la récupère via une mise à jour du système d'exploitation, une mise à jour d'application ou, sur les serveurs, un paquet tel que `tzdata`.

C'est aussi dans ce pipeline que naissent les bugs du monde réel. La base peut être parfaitement à jour alors qu'un appareil donné ne l'est pas. Un ordinateur portable qui a manqué la mise à jour continue d'appliquer l'ancienne règle, et l'horloge est fausse le jour de la transition. L'écart entre « la règle a changé » et « tous les appareils le savent » est de loin la principale source des bugs de fuseaux horaires que vous rencontrerez réellement.

Pourquoi les décalages codés en dur deviennent obsolètes

Voici l'erreur que tout le système existe pour éviter. Un développeur décide de stocker le fuseau horaire d'un utilisateur sous la forme d'un simple nombre — `+1` — parce que cela paraît efficace. C'est cassé de trois manières à la fois.

• Cela ignore le DST. `Europe/Paris` est en UTC+1 l'hiver et en UTC+2 l'été. Un `+1` stocké n'est correct qu'une partie de l'année, et chaque printemps et chaque automne le calcul dérive d'une heure.
• Cela ne peut pas représenter la transition elle-même. Le matin où l'horloge avance, une heure locale n'existe pas ; le matin où elle recule, une heure locale se produit deux fois. Un simple décalage n'a aucun moyen de dire « 02:30 a eu lieu deux fois ». Une zone nommée, appliquée selon une logique de date correcte, le peut.
• Cela fige une règle qui va changer. Si une région abolit le DST l'année prochaine, la base tz publie une mise à jour et tous les systèmes conformes s'adaptent automatiquement. Un `+1` codé en dur continue d'appliquer indéfiniment la politique de l'an dernier, produisant en silence des heures erronées.

Un exemple concret, avec des décalages vérifiés

Planifiez un appel récurrent tous les lundis à 09:00 à Berlin, auquel se joint une personne à Chicago. Observez l'écart évoluer au fil de l'année :

• Mi-janvier : Berlin est en CET (UTC+1), Chicago en CST (UTC−6). L'écart est de 7 heures, l'appel a donc lieu à 02:00 à Chicago.
• Mi-juillet : les deux sont passés à l'heure d'été — Berlin en CEST (UTC+2), Chicago en CDT (UTC−5). Toujours 7 heures, donc toujours 02:00 à Chicago.
• Mi-mars : les deux pays ne changent *pas* d'heure le même jour. En 2025, les États-Unis sont passés à l'heure d'été le 9 mars, mais l'UE pas avant le 30 mars. Pendant ces trois semaines, Chicago était déjà en CDT (UTC−5) tandis que Berlin était encore en CET (UTC+1) — un écart de seulement 6 heures, plaçant l'appel à 03:00 à Chicago.

Un outil qui aurait stocké « Berlin = +1, Chicago = −6 » se tromperait d'une heure en juillet *et* pendant les semaines de chevauchement de mars. Seul un système qui résout les zones nommées en fonction de la *date précise* tombe juste chaque semaine. C'est exactement ainsi que fonctionnent le planificateur de réunions et le convertisseur de Timezio : ils demandent de quel lieu vous parlez, puis appliquent les règles en vigueur pour la date concernée plutôt qu'un nombre figé.

Une checklist pratique

Vous n'avez jamais besoin d'ouvrir un fichier tzdata pour profiter de son fonctionnement. Cinq habitudes en tirent toute la valeur au quotidien :

• Stockez et partagez des lieux, pas des décalages. « Je suis dans `America/Los_Angeles` » survit aux changements de DST et de politique. « Je suis à UTC−8 » non.
• Maintenez vos systèmes à jour. La raison la plus fréquente pour laquelle une horloge est fausse un week-end de transition est un appareil qui a manqué la dernière version de `tzdata`. Les mises à jour du système et des applications sont la façon dont le correctif vous parvient.
• Méfiez-vous de tout outil qui affiche un unique décalage fixe pour une ville. S'il ne tient pas compte de la date, il ne peut pas tenir compte du DST.
• Revérifiez les événements transfrontaliers autour des week-ends de changement d'heure et après toute annonce gouvernementale. C'est précisément à ce moment-là que l'écart entre règle et mise à jour mord le plus fort.
• Considérez chaque réponse comme provisoire. La conversion correcte d'aujourd'hui ne l'est que jusqu'au prochain décret.

La base de données de fuseaux horaires IANA est l'une des pièces d'infrastructure partagée les plus discrètes du web — un ensemble de fichiers texte maintenu par des bénévoles sur lequel le monde numérique s'appuie pour l'heure civile. Elle fonctionne parce qu'elle traite les fuseaux horaires pour ce qu'ils sont réellement : une cible mouvante façonnée par la politique, et non une grille fixe tracée sur une carte. Chaque conversion exacte sur laquelle vous comptez, y compris celles de Timezio, dépend du fait que quelqu'un, quelque part, ait consigné la dernière règle et l'ait diffusée avant que les horloges ne changent.