Fuseau horaire IANA

Un fuseau horaire IANA est un identifiant canonique comme Europe/London, America/New_York, ou Asia/Tokyoissu de la base de données IANA des fuseaux horaires (aussi appelée “tzdata” ou “base Olson” d’après son créateur original, Arthur David Olson).

Chaque entrée capture toutes les règles historiques et actuelles concernant le décalage UTC et le comportement de l’heure d’été pour une région. “Europe/London” encode : GMT (UTC+0) en hiver, BST (UTC+1) en été, les dates précises de transition DST, ainsi que les particularités historiques antérieures à 1971. Associer une date et un fuseau dans n’importe quel langage de programmation moderne retourne le bon décalage car tzdata est intégré au système d’exploitation.

La convention de nommage est Région/Ville, où Région est l’une des valeurs Africa, America, Antarctica, Asia, Atlantic, Australia, Europe, Indian, Pacific, plus les spéciaux UTC, Etc/GMT, etc. La ville est une ville canonique dans la zone — Istanbul représente toute la Turquie, New_York représente le fuseau EST des États-Unis, et ainsi de suite.

Le convertisseur de fuseaux horaires de Convertitive fonctionne avec les données tzdata au niveau OS du navigateur via Intl.DateTimeFormat, de sorte que les transitions DST et les changements de décalage sont toujours à jour sans que Convertitive ait à publier des mises à jour.

Exemple concret

Vous planifiez une réunion hebdomadaire récurrente “chaque mardi à 09h00 heure de New York” pour des participants à New York, Londres et Tokyo. Stockez la réunion comme { rrule: "FREQ=WEEKLY;BYDAY=TU", time: "09:00", tz: "America/New_York" }. Le calendrier du participant londonien résout chaque occurrence : en janvier, New York est en EST (UTC−5) et Londres en GMT (UTC+0), donc la réunion est à 14h00 à Londres. En mars (après le début de l’heure d’été américaine mais avant celle de l’UE), New York est en EDT (UTC−4) et Londres en GMT, donc la réunion est à 13h00 à Londres — avancée d’une heure. En juin, les deux sont à l’heure d’été, EDT (UTC−4) et BST (UTC+1), donc la réunion est à 14h00 à Londres. Tokyo (UTC+9, sans heure d’été) voit la réunion osciller entre 22h00 et 23h00 selon la saison. Imaginez maintenant que l’équipe ait stocké la réunion comme “14h00 UTC” — le participant new-yorkais verrait l’horaire dériver au gré des transitions DST, et la convention “mardi 9h” se briserait silencieusement deux fois par an.

Quand et pourquoi c’est important

Les fuseaux horaires IANA deviennent indispensables dès qu’un système traite des dates pour plusieurs utilisateurs, plusieurs emplacements ou plusieurs saisons. L’erreur à éviter au stockage est d’utiliser des décalages fixes — “Asia/Karachi” survivra à une future réintroduction de l’heure d’été ; “UTC+5” ne le sera pas. L’erreur à éviter à l’affichage est de restituer des horodatages sans préciser la zone de destination — un journal de bord affichant “2026-05-22 14:30” sans indication de zone est ambigu et introuvable. L’erreur à éviter dans la logique métier est d’effectuer des calculs “ajouter 1 jour” en UTC plutôt qu’en heure locale autour des transitions DST — “le lendemain à la même heure” peut représenter 23 ou 25 heures en UTC selon que la DST commence ou non cette nuit-là. Les bibliothèques datetime modernes (API Temporal de JavaScript, zoneinfo de Python, java.time de Java) gèrent correctement ce cas avec des identifiants IANA ; les anciennes API produisent silencieusement des résultats incorrects. Référence : RFC 6557 — Procédures de maintenance de la base de données des fuseaux horaires.

Le cycle de publication de tzdata IANA :les versions de tzdata sont numérotées par année + lettre minuscule — 2024a, 2024b, 2025a, etc. Les publications interviennent à la demande, généralement 4 à 8 fois par an, lorsqu’un gouvernement modifie les règles DST ou le décalage UTC d’une région. Changements récents notables : le Mexique a aboli l’heure d’été à l’échelle nationale en 2022 ; la Russie a abandonné puis rétabli l’heure d’hiver permanente à travers plusieurs révisions ; le Liban a eu un début de DST retardé d’une semaine en 2023 en raison d’un différend politique. Chaque OS intègre ces modifications via les mises à jour de paquets régulières — mais les appareils IoT et les vieux téléphones qui ne se mettent pas à jour automatiquement peuvent dériver, causant le classique problème “mon réveil est décalé d’une heure” dans la première semaine suivant un changement de règle DST.

Pourquoi ne jamais stocker directement des décalages :l’erreur la plus courante dans le code datetime est de stocker “UTC+2” au lieu de Europe/Istanbul. Le décalage capture un fait ponctuel sur la zone mais pas les règles. Si la Turquie réintroduit l’heure d’été (elle l’a abolie en 2016, mais les changements de règles sont fréquents dans la région), chaque enregistrement avec “UTC+2” devient erroné du jour au lendemain. Stockez l’identifiant de zone IANA et laissez la recherche calculer le bon décalage pour chaque horodatage. Connexe : UTC, seconde intercalaire. Référence : Base de données IANA des fuseaux horaires.