- Les fuseaux horaires sont complexes, mais comme les ordinateurs doivent les implémenter, leur étrangeté reste limitée à un cadre fini.
Asia/Kathmandua un décalage inhabituel par rapport à l’UTC.Africa/Casablancas’adapte mal au modèle des fuseaux horaires, donc il est géré en dur.America/Nuukpasse à l’heure d’été à -01:00.Africa/CairoetAmerica/Santiagopassent à l’heure d’été à 24:00 (et non à 00:00).Australia/Lord_Howea la règle d’heure d’été la plus étrange.
PGXIIREAM : le pape Grégoire XIII gouverne tout
- La majeure partie du monde utilise un système horaire fondé sur le calendrier grégorien.
- Le calendrier grégorien est très utile pour maintenir la position du soleil cohérente tout au long de l’année.
- L’UTC est la formalisation officielle moderne du calendrier grégorien, et le monde entier règle son heure sur cette base.
Les secondes intercalaires n’ont pas d’importance
- La rotation de la Terre ralentit, et on ajoute des secondes intercalaires pour compenser.
- On peut les ignorer, car les langages de programmation ne représentent pas une 61e seconde.
- Les fournisseurs cloud résolvent le problème en ralentissant l’horloge pendant les secondes intercalaires.
Fuseaux horaires étranges
Asia/Kathmandu a un décalage inhabituel
- Le Népal a 5 heures et 45 minutes d’avance sur l’UTC.
- Les ordinateurs le savent grâce à la base de données des fuseaux horaires de l’IANA.
Les chaînes comme PDT ou CET n’ont pas de sens
- Les identifiants de fuseau horaire peuvent être ambigus, et de nombreux fuseaux partagent le même identifiant.
Comment représente-t-on les fuseaux horaires avec heure d’été ?
- Les règles de transition vers l’heure d’été sont complexes, et les ordinateurs calculent l’heure locale à partir de celles-ci.
Africa/Casablanca et Asia/Gaza suivent la lune, alors que les fuseaux horaires suivent le soleil
- Le Maroc et Gaza ajustent l’heure d’été en fonction du ramadan, ce qui est géré en dur.
America/Nuuk passe à l’heure d’été à -1:00
- Le Groenland commence l’heure d’été au même moment que l’Europe, mais en heure locale cela se produit à -1:00.
America/Santiago et Africa/Cairo basculent à 24:00
- Ces fuseaux passent à l’heure d’été à 24:00, ce qui signifie le passage au jour suivant.
Australia/Lord_Howe a la transition d’heure d’été la plus étrange
- L’île Lord Howe applique une transition d’heure d’été de 30 minutes.
Résumé de GN⁺
- Les fuseaux horaires sont complexes, mais comme les ordinateurs doivent les implémenter, leur étrangeté reste limitée à un cadre fini.
Australia/Lord_Howeest le fuseau horaire le plus singulier avec sa transition d’heure d’été de 30 minutes.- Cet article aide à comprendre la complexité des fuseaux horaires et peut intéresser les programmeurs.
- Un projet aux fonctionnalités similaires est
tzdb.
1 commentaires
Avis sur Hacker News
La partie la plus amusante de la base de données tz est qu’elle contient une estimation de l’instant du Big Bang, et qu’elle est conçue pour ne pas calculer les changements de fuseau horaire survenant avant le Big Bang.
Le message de commit de https://github.com/eggert/tz/commit/b22d459a367f4d01b10f6f6b... disait aussi, en substance, « ne générons pas de timestamps antérieurs au Big Bang, ils sont physiquement douteux », et peu après, un commit séparé a également interdit les secondes intercalaires antérieures au Big Bang.
datequi traitait de la signification des dates anciennes.Avec des exemples autour du XVe siècle, elle racontait qu’un roi aimait telle semaine ou tel mois et avait ordonné de le répéter, ou qu’un autre roi détestait telle semaine et l’avait supprimée du calendrier. C’était une lecture assez éclairante, mais je n’arrive plus à la retrouver.
Autrement dit, la conclusion est : « les instants antérieurs au Big Bang sont hors du périmètre de cette bibliothèque ; donc si un algorithme ne produit de mauvaises valeurs qu’avant le Big Bang, cet algorithme est acceptable et n’a pas besoin d’être amélioré ou remplacé ».
L’utilité par rapport aux bugs potentiels ne me paraît pas énorme, et l’essentiel de la complexité désordonnée de tzdb se trouve dans
zic. Parfois, j’ai l’impression qu’il aurait mieux valu quezicne soit pas un artefact sur lequel d’autres puissent dépendre.J’aimerais que les fuseaux horaires eux-mêmes disparaissent avant que la théorie des fuseaux horaires ne devienne obsolète.
À mon avis, le fuseau horaire le plus étrange est Africa/Addis_Ababa. Les Éthiopiens sur place, eux, n’utilisent pas vraiment cette façon de faire.
Localement, on décale l’heure de 6 heures : le cycle AM commence à l’aube, c’est-à-dire à 6 h du matin, et le cycle PM commence au coucher du soleil, à 18 h.
https://en.wikipedia.org/wiki/Time_in_Ethiopia
De même, la journée se termine à 18 h, thenashara. Intuitivement, c’est bien plus logique que l’horloge anglophone, et comme c’est intégré dans la langue, les confusions d’heure sont rares.
https://en.wikipedia.org/wiki/Ethiopian_calendar
Le calendrier éthiopien se compose de 12 mois de 30 jours et d’un 13e mois formé de 5 ou 6 jours épagomènes.
https://en.wikipedia.org/wiki/Roman_timekeeping
Dans le monde anglophone aussi, autrefois, l’année changeait le 25 mars : https://en.wikipedia.org/wiki/Calendar_(New_Style)_Act_1750#...
Techniquement, aucun des deux n’entre dans le champ de tzdb. tzdb traite l’heure civile, pas les calendriers ni les autres modes de calcul.
L’étrangeté de
Asia/Jerusalemvient du fait que l’heure d’été y est fortement liée à la question de la séparation entre religion et État. Les personnes religieuses veulent que les journées de travail soient pratiques par rapport aux fêtes qui commencent au coucher du soleil.Ainsi, jusqu’au milieu des années 2000, pendant des décennies, l’heure d’été résultait chaque année de négociations entre partis religieux et partis laïcs, et les dates de changement n’étaient décidées qu’au dernier moment, ce qui causait souvent des problèmes.
Il existe encore une exception visant à éviter que l’heure d’été ne se termine à Rosh HaShanah, ce qui semble rendre les règles futures complexes.
Si l’UE finit par réussir à l’abolir, ils suivront peut-être.
On ne veut donc pas que l’heure d’été rende encore plus tardif un événement qui se termine déjà tard. De plus, pour le jour de jeûne de Yom Kippour, on voulait que le jeûne se termine une heure plus tôt. En essayant de s’aligner sur ces dates, la période d’heure d’été devenait trop courte, ce qui nécessitait des négociations.
L’affirmation selon laquelle « les langages de programmation ne peuvent pas représenter une minute de 61 secondes » n’est pas vraie. Quelqu’un a déjà mentionné que Raku prend en charge les secondes intercalaires, et c’est peut-être en partie de ma faute
La raison est que
DateTime.pm, la bibliothèque date/heure la plus populaire de Perl 5, prend en charge les secondes intercalaires, et c’est moi qui ai implémenté ce support en créantDateTime.pmAvec le recul, c’était presque certainement une erreur. Presque personne ne s’intéresse aux secondes intercalaires, et cela ne fait que créer des confusions bizarres du genre « pourquoi ajouter 60 secondes n’est-il pas toujours la même chose qu’ajouter 1 minute ? »
Le code est devenu beaucoup plus complexe, notamment parce qu’il fallait vérifier si
second => 60était valide. Le constructeur accepte des composants temporels et un fuseau horaire arbitraire ; pour consulter la table des secondes intercalaires, il faut donc convertir en UTC, mais cette conversion elle-même se retrouve, pour des raisons historiques, mêlée à des valeurs incluant des secondes intercalairesC’est devenu un énorme bazar pour un bénéfice minuscule, et comme la bibliothèque standard date/heure de Raku semble aussi beaucoup emprunter à
DateTime.pmde Perl 5, j’ai l’impression qu’elle a hérité d’une partie des mêmes mauvais choix de conceptionJe me demande quel était le raisonnement initial. Était-on trop absorbé par le problème ? Quand on est trop proche d’un problème et qu’on se concentre dessus trop longtemps, le plaisir de le réparer avant qu’il ne casse peut parfois conduire à ce genre de situation
Elle est définie, en substance, comme « un instant précis mesuré en secondes atomiques et en fractions de celles-ci, qui n’est lié à aucune epoch et n’en a pas connaissance »
Plus tôt cette année, j’ai dû écrire une fonction qui, à partir d’une adresse américaine, trouvait l’heure locale actuelle. L’approche naïve consiste à associer statiquement l’État au fuseau horaire, mais il existe pas mal d’exceptions qui empêchent de faire cela
Dans cette application, le coût et la rapidité étaient importants ; j’ai donc acheté pour quelques dollars un CSV qui associait tous les ZIP codes américains à un décalage UTC, au respect ou non de l’heure d’été, etc.
Comme
pytzattend des noms de fuseaux horaires IANA, j’ai finalement dû faire manuellement la correspondance entre les informations de décalage et d’heure d’été et des fuseaux horaires précis ; les territoires américains d’outre-mer et les bases militaires ont aussi rendu nécessaires des sémantiques étranges comme les fuseauxEtc[1] https://en.wikipedia.org/wiki/Tz_database#Area
Les ZIP codes peuvent probablement suffire, mais il faut être prudent. Si le nombre d’adresses n’est pas trop élevé, une approche plus robuste consiste à faire du géocodage inverse, puis à utiliser une bibliothèque qui obtient l’identifiant IANA à partir des polygones de limites de fuseaux horaires
https://github.com/RomanIakovlev/timeshape est maintenu par un ancien collègue, et nous avons pu publier en open source une partie du travail que nous avions fait en interne
Un ou deux systèmes horodataient les données en heure locale, les autres utilisaient l’UTC. Pour concevoir un algorithme de gestion de l’heure d’été, j’ai acheté un vieux Farmers' Almanac, mais j’ai désespéré en lisant les règles
Le calendrier contenait les règles nominales de changement d’heure, mais une note indiquait qu’elles avaient été ajustées d’année en année en raison d’interventions du Congrès, et qu’elles continueraient probablement à l’être. J’ai dit à mon chef : « si je pouvais écrire un algorithme capable de prédire les votes futurs du Congrès, je serais milliardaire et j’aurais quitté ce boulot d’ingénieur »
Je crois qu’au final, j’ai codé les transitions connues les plus récentes ainsi que les règles nominales futures. C’était avant que tout le monde soit connecté au réseau, et le code tournait sur des machines autonomes comme des VAX ; il n’y avait donc pas beaucoup d’autres options
Fusionner trois sources de données de suivi, chacune avec ses états de validité et de dégradation de la qualité des mesures, était aussi un cauchemar, mais c’était quand même plus facile que de prédire les actions futures du Congrès
US/Eastern. Ensuite, si l’on a besoin du décalage UTC, on applique ce fuseau à la date concernée avecpytzpour obtenir le décalageLes fuseaux horaires nommés ont ceci de particulier qu’ils sont stables. Les fuseaux basés sur un décalage UTC comme
-05:00, ou les abréviations commeEST, ne sont pas stables dans le temps pour un lieu donné à cause de l’heure d’étéSi l’on demande son fuseau horaire à quelqu’un en lui proposant des décalages ou des abréviations, tout le monde finit par être perdu
Pour la conversion latitude/longitude → fuseau horaire, j’ai utilisé cette bibliothèque Python : https://github.com/jannikmi/timezonefinder
La source des données semblait elle aussi d’assez bonne qualité : https://github.com/evansiroky/timezone-boundary-builder/rele...
Etc, surtout si l’on envisageait d’exposer tous les identifiants tels quels aux utilisateursLe fichier contient un commentaire disant : « POSIX considère comme positifs les fuseaux à l’ouest de Greenwich, mais beaucoup de gens s’attendent à ce que les valeurs positives soient à l’est de Greenwich. Par exemple,
TZ='Etc/GMT+4'utilise l’abréviation-04et désigne un fuseau 4 heures en retard sur UT, donc à l’ouest de Greenwich, alors que beaucoup de gens s’attendent à un fuseau 4 heures en avance sur UT, à l’est »Le fuseau horaire de la Palestine est aussi assez étrange
https://en.wikipedia.org/wiki/Time_in_the_State_of_Palestine
Il existe une heure d’été, mais les dates ne sont pas fixes : le gouvernement annonce chaque année les dates de début et de fin. Parfois, l’annonce arrive moins d’une semaine à l’avance, ce qui ne peut que provoquer toutes sortes de problèmes intéressants.
Les dates de début et de fin de l’heure d’été en Israël et en Palestine ne coïncident pas forcément
Dire qu’une heure d’été décalée de 30 minutes au lieu d’une heure est le « fuseau horaire le plus étrange » me paraît mettre la barre très bas
Presque tout le reste est plus étrange. Antarctica/Troll paraît clairement plus bizarre, et les fuseaux horaires du Maroc et de Gaza ont au moins des règles d’un autre type, au point qu’on ne peut pas les exprimer avec les systèmes existants. Les fuseaux qui changent la veille d’une date donnée, et qui figurent sur la liste noire d’Apple, sont eux aussi assez étranges pour casser des choses
Je suis d’accord à propos des secondes intercalaires. C’est presque de la culture générale, plus qu’un savoir utile que les programmeurs devraient connaître. Les ordinateurs les lissent, et ne savent même pas quand elles se produisent. On peut parfaitement les oublier
Cela dit, certains pays sont passés d’une façon d’ignorer les secondes intercalaires à une façon de les prendre en compte ; ainsi, il y a quelques décennies, le passage en Australie de
GMT+xàUTC+xa marqué la transition entre leur ignorance et leur inclusion. Le fait que ce soit presque universellement ignoré est peut-être plutôt une bonne choseMais il y a toujours quelque chose d’un peu drôle quand une grande organisation dit : « nos serveurs ont une précision temporelle inférieure à la milliseconde grâce à la synchronisation GPS et à des cartes PCIe maison avec horloge atomique au rubidium », tout en disant en même temps : « nous lissons les secondes intercalaires sur une journée, donc en pratique ça ne nous dérange pas si l’heure du serveur est fausse de ±0,5 seconde »
[1] https://engineering.fb.com/2021/08/11/open-source/time-appli...
[2] https://engineering.fb.com/2020/03/18/production-engineering...
Par exemple, si le ciel est très couvert, on ne voit pas la lune, où qu’elle soit. Cela pose problème quand il faut implémenter un calendrier pour administrer un pays
De nombreux pays qui ont officiellement adopté le calendrier islamique utilisent des dates approximatives calculées à l’avance, fondées sur la visibilité prévue depuis un lieu donné. Le calendrier islamique n’est donc pas vraiment unique : il ressemble plutôt à deux calendriers, un calendrier islamique d’observation et un calendrier prédictif, tous deux dépendant du lieu où l’observation réelle ou prévue est effectuée
Je ne sais pas comment le Maroc ou Gaza procèdent
Sauf que l’heure de la Norvège utilise justement l’heure d’été
Beaucoup de marchés ont fermé pendant les secondes intercalaires, et beaucoup de banques interrompent encore toutes les transactions lors des changements d’heure locale afin de réduire les risques d’erreur
Même dans des applications qui s’en soucient peu, il y a eu un nombre surprenant de bugs liés aux secondes intercalaires, et le CGPM avait de bonnes raisons de décider leur suppression
https://en.wikipedia.org/wiki/Leap_second#Other_reported_sof...
Excellent article sur les acrobaties des logiciels de fuseaux horaires. Ils sont vraiment assez flexibles.
Si tout n’est qu’un ensemble fini de décalages automatisés, il n’y a aucune raison pour que les règles d’heure d’été se limitent forcément à des ajustements de 60 minutes.
Un pays pourrait-il décider d’utiliser toute l’année un décalage qui varie en continu ? La table de correspondance des décalages deviendrait beaucoup plus longue, mais cela pourrait « résoudre » l’heure d’été. Comme l’ajustement se ferait par petites touches constantes, on ne le remarquerait pas, un peu comme les secondes intercalaires.
Les personnes qui dépendent de montres analogiques ne les régleraient peut-être plus toujours dans le même sens.
Un changement de 10 minutes une fois par mois est beaucoup plus facile à absorber, passe presque inaperçu, et si on le rate, ce n’est pas aussi grave que d’avoir une heure de décalage.
Il suffit d’arrêter l’heure d’été. Personnellement, je préfère une heure standard permanente à une heure d’été permanente, mais tant qu’on peut arrêter de changer les horloges deux fois par an, ça me va.
La Chine, bien sûr, est célèbre pour n’avoir qu’un seul fuseau horaire malgré son immense étendue, ce qui crée des situations intéressantes aussi bien en interne qu’avec l’extérieur.
Une hypothèse vraiment importante, qui n’apparaît pas clairement dans le format de données TZif, est que lorsqu’on passe de l’heure locale à l’heure UTC, il n’y a au maximum que deux possibilités.
Beaucoup de logiciels reposent sur cette hypothèse ; par exemple,
java.time.LocalDateTimepossèdewithLaterOffsetAtOverlap(): https://docs.oracle.com/javase/8/docs/api/?java/time/LocalDa...Cela suppose implicitement que lorsque le sens de 2 h 30 du matin est ambigu, les seules solutions possibles sont les deux offsets avant et après l’heure d’été. Si un fuseau horaire reculait une première fois à 2 h, puis encore à 2 h 15, produisant ainsi trois solutions ou plus, beaucoup de choses ne pourraient pas le représenter.
Ce que j’aime dans la base de données tz, c’est qu’elle est techniquement un diff de diff.
Elle stocke la manière dont l’écart entre chaque fuseau horaire et UTC a varié au fil de l’histoire, on peut donc y voir un
diff^2. Mais comme la base de données tz reçoit aussi des mises à jour, ces commits sont des diffs de diffs de diffs, autrement dit desdiff^3.On peut aller plus loin. Il y a un journal des modifications, et ce journal est stocké dans git ; un commit sur le journal des changements de tz est donc une modification de la liste de modifications de la liste de modifications de la liste de modifications par rapport à UTC, soit un
diff^4.Pour moi, le cadrage essentiel est que presque toutes les dates/heures sont en réalité un ensemble de règles de correspondance sous surveillance.
On peut estimer combien de secondes il faudra avant qu’une correspondance se déclenche, mais on ne peut pas en être totalement certain avant que cela se produise réellement, et dans certains cas cela peut même ne jamais se produire exactement.
L’autre moitié consiste ensuite à reconvertir l’estimation de delta « cela devrait arriver dans X secondes à partir de maintenant » en « à ce moment-là, l’horloge de votre fuseau horaire devrait afficher Y ».
Il ne faut pas oublier de suivre en permanence quel fuseau horaire contrôle l’événement, et dans quel fuseau horaire il est affiché.
[1] Les estimations en UTC peuvent être décalées vers l’avant ou l’arrière d’une seconde intercalaire. TAI est plus sûr, mais cela pourrait changer si quelqu’un découvrait quelque chose de nouveau et d’intéressant qui modifie le comportement des atomes de césium.
[0] Par exemple, un pays peut disparaître et son fuseau horaire avec lui. Ou bien l’horloge peut sauter de 1 h 00 à 2 h 00, de sorte que l’intervalle de 1 h 30 à 2 h 00 n’arrive jamais exactement à cause de l’heure manquante.