Skip to main content
Retour aux billets
Oct. 202612 min de lecture

L'Alberta a cessé de changer ses horloges en juin. Les 19 modèles de pointe placent encore Calgary à l'heure normale en novembre.

Le 18 juin 2026, l'Alberta a cessé de changer ses horloges. La Colombie-Britannique l'avait fait en mars, les Territoires du Nord-Ouest ont suivi en août, le Maroc est revenu à l'UTC pur en septembre. Tout cela est dans la base de données qui fait tourner l'horloge de votre téléphone, et rien de cela n'est dans un modèle entraîné avant la mi-2026. J'ai donc posé à 19 modèles sur Kaggle Benchmarks la question que quelqu'un à Calgary se pose vraiment : il est 9 h ici le 15 novembre, quelle heure est-il à Toronto ? La réponse est 10 h et les 19 ont dit 11 h. J'ai ensuite noté la même copie contre chaque version de tzdata depuis 2022, ce qui date l'horloge de chaque modèle au mois où elle s'est arrêtée.

Kaggle BenchmarksDEV ChallengeIANA tzdataKnowledge cutoffLLM evaluationTool useGPT-6 AstraGeminiClaudeHackathon
J'ai écrit ce billet pour le DEV x Kaggle Benchmarking Challenge (23 septembre au 11 octobre 2026), et j'ai bâti World Clock pour la même soumission. Le banc d'essai est public sur Kaggle sous le nom world-clock, en deux tâches, de mémoire et avec un outil tzdata. Le code, le corrigé, tous les résultats et les deux graphiques sont sur github.com/JonathanSolvesProblems/world-clock, ouverts, sans clé et sans compte. #kagglechallenge
La revendication en une phrase : sur 122 questions corrigées contre IANA tzdata 2026d, une base publique que je n'ai pas écrite et sur laquelle je n'ai aucune prise, 13 des 19 modèles de pointe n'ont obtenu aucune des 20 réponses qui ont changé en 2026, et les 19 ont placé Calgary au mauvais décalage en novembre. Le correcteur les date aussi : noter la même copie contre les vingt versions de tzdata depuis 2022 place l'horloge de GPT-6 Astra à la version d'avril 2026, contre une date de coupure annoncée au 30 avril 2026, à partir de rien d'autre que des questions d'horloge. Ce qui n'est pas revendiqué : que la datation soit exacte pour chaque modèle. Un modèle qui s'accorde avec sa version sommet sur 46 des 46 réponses modifiées a une horloge nette ; un modèle à 34 sur 46 en a une floue et sa date est un meilleur ajustement, donc le tableau publie les deux chiffres.
Un 11:00 barré à côté d'un 10:00 correct, avec la mention 19 modèles sur 19 interrogés de mémoire sur Kaggle Benchmarks contre la base de fuseaux horaires de l'IANA 2026d, et une note indiquant que l'Alberta a cessé de changer ses horloges le 18 juin.
Tout le banc d'essai en une image. Il est 9 h à Calgary le 15 novembre 2026. À Toronto il est 10 h. Tous les modèles interrogés ont répondu 11 h, et la plupart ont cité la même règle : l'heure avancée se termine le premier dimanche de novembre. Cette règle a été vraie en Alberta pendant 55 ans.

Un corrigé que personne n'a à écrire

Les connaissances de chaque modèle s'arrêtent à sa date de coupure, et la plupart du temps on ne voit pas le bord. Les fuseaux horaires, c'est différent. Les gouvernements les changent par loi, à une date précise, et la base de fuseaux horaires de l'IANA consigne chaque changement en quelques jours. Ça donne à un banc d'essai deux choses que la plupart n'ont jamais : un corrigé que personne n'a à écrire, et un calendrier contre lequel tenir les connaissances du modèle. Ici le corrigé est tzdata 2026d, la version de septembre de la base même qui fait tourner l'horloge de votre téléphone, et je n'ai tapé aucune réponse attendue. Un script demande au module zoneinfo de Python ce qu'a fait l'horloge à tel endroit à telle date, et c'est ça la vérité. Les mainteneurs publient quelques versions par année, donc le corrigé se réécrit tout seul et le banc d'essai ne périme pas. 125 questions sur six familles : des contrôles classiques comme New York et Tokyo, des décalages inhabituels comme Katmandou à +05:45 et l'heure avancée d'une demi-heure de l'île Lord Howe, les saisons de l'hémisphère sud, les changements légiférés entre 2022 et 2025 en Iran, en Jordanie, au Mexique, au Kazakhstan et au Chili, et la vague de 2026. Les réponses reviennent en sortie structurée et la correction est une comparaison de chaînes après normalisation des décalages, donc une mauvaise heure est une mauvaise heure et il n'y a aucun modèle juge dans la boucle.

Deux diagrammes à barres côte à côte. À gauche, la part des questions classiques réussies de mémoire, où chaque modèle est près du haut de l'échelle. À droite, les réponses modifiées de 2026 réussies sur 20, où presque chaque barre est à zéro.
Les fuseaux horaires comme sujet, c'est appris. Quinze des 19 ont réussi les 26 questions de contrôle et personne n'est descendu sous 23. Les fuseaux horaires à une date donnée, c'est tout autre chose, et c'est l'écart que mesure le graphique de droite.

Personne n'est au courant pour l'Alberta

Vingt des 25 questions sur la vague de 2026 ont une réponse qui a changé cette année. Treize des 19 modèles n'en ont réussi aucune, dont Claude Opus 5, GPT-5.5, GPT-5.6 Terra et trois des cinq Gemini. Sur l'ensemble des 19 modèles, il y a eu 18 bonnes réponses à ces 20 questions, et GPT-6 Astra en a produit 5, dont quatre sur la Colombie-Britannique avec la bonne raison à l'appui. J'ai lu chacune des 13 autres bonnes réponses, et aucune de ces notes ne dit que quoi que ce soit a changé en 2026 : elles sont justes par accident. Qwen a dit que les horloges ne changent pas le 1er novembre parce que le recul a lieu le 2 novembre, qui n'est pas un dimanche. Gemini 2.5 Pro a dit que les horloges d'Inuvik ne changent pas parce que les Territoires du Nord-Ouest observent l'heure avancée des Rocheuses à l'année, puis a placé Inuvik à l'autre décalage à la question suivante. La question du décalage de Calgary est celle que je mettrais devant un juge, parce qu'on ne peut pas y répondre juste par accident : Calgary à midi le 15 novembre 2026, c'est -06:00, et les 19 modèles ont répondu -07:00.

Une grille de 19 noms de modèles, chacun avec le nombre de réponses modifiées de 2026 réussies sur 20. La plupart affichent zéro, avec une ligne en dessous indiquant que 13 sur 19 n'en ont obtenu aucune.
Treize zéros. Le meilleur score du tableau est de 5 sur 20, obtenu par le modèle le plus récent du lot, et les modèles de 2025 sont éparpillés au milieu plutôt qu'au bas, ce qui est un constat en soi.

Dater les horloges

C'est la partie pour laquelle tout le banc d'essai a été bâti. Sur les 122 questions corrigées, 46 ont une réponse qui a changé d'une version de tzdata à une autre. Je garde décompressées toutes les versions depuis 2022a, vingt en tout, je note la copie de chaque modèle contre les vingt, et la version avec laquelle il s'accorde le plus est le mois où son horloge du monde s'est arrêtée. GPT-6 Astra donne le résultat le plus net du lot. Sa courbe monte à travers chaque version depuis 2022, s'accorde avec tzdata 2026b sur 45 des 46 réponses modifiées, et s'effondre à la suivante. tzdata 2026b est sortie le 22 avril 2026 et c'est la première à porter la Colombie-Britannique ; la version d'après est arrivée le 8 juillet. L'échelle dit donc que cette horloge s'est arrêtée entre ces deux dates, et OpenAI annonce une date de coupure au 30 avril 2026. Les deux concordent, et l'échelle y est arrivée à partir de rien d'autre que des questions sur l'heure qu'il est. La même méthode place GPT-5.5, GPT-5.6 Terra et Claude Opus 5 sur une courbe commune à la dernière version avant la Colombie-Britannique, avec un parfait 46 sur 46 chacun.

Un graphique linéaire des réponses correspondant à chaque version de tzdata sur les 46 modifiées, avec la courbe de GPT-6 Astra mise en évidence, montant vers un sommet à tzdata 2026b publiée le 22 avril 2026 et chutant brusquement ensuite, annotée avec la date de coupure annoncée par OpenAI du 30 avril 2026.
L'échelle. Tout ce qui précède le sommet est juste, tout ce qui suit est faux, et le sommet tombe quatre jours avant la date de coupure publiée par le fournisseur. Rien dans ce graphique ne sait ce qu'est une date de coupure ; il sait seulement quelle heure le modèle croit qu'il est à vingt endroits.

L'autre résultat de ce graphique est celui que je n'attendais pas. Gemini 2.5 Pro de juin 2025, Gemini 3.1 Pro de février 2026, Gemini 3.7 Flash d'août 2026 et Gemini 3.8 Flash de septembre 2026 culminent tous à la même version, tzdata 2025a du 15 janvier 2025, et les deux courbes Flash ne diffèrent jamais de plus d'une réponse où que ce soit sur l'échelle. La fiche de modèle de Google pour la 3.8 Flash donne une date de coupure de mars 2026 pour certains domaines et de janvier 2025 pour le reste. L'horloge fait partie du reste, et elle n'a pas bougé en quinze mois de sorties de modèles. La date de sortie n'est pas l'horloge, et ça vaut la peine de le dire clairement parce que la date de sortie est ce vers quoi la plupart des gens se tournent pour savoir à quel point un modèle est à jour.

Le même graphique d'échelle avec trois courbes Gemini mises en évidence, Gemini 2.5 Pro, 3.7 Flash et 3.8 Flash, culminant toutes ensemble à tzdata 2025a de janvier 2025.
Trois modèles sortis à quinze mois d'intervalle, une seule horloge. Le modèle de juin 2025 et celui de septembre 2026 culminent à la même version de janvier 2025.

Vérifier n'est pas croire

J'ai ensuite reposé un sous-ensemble avec un outil sur la table. Une seule fonction, zone_clock, qui lit tzdata 2026d et renvoie le décalage en vigueur. La consigne dit que l'outil existe et que le modèle peut l'appeler ou répondre sans. Rien ne dit au modèle que ses connaissances pourraient être périmées. Presque tous vérifient : onze des 16 modèles ont interrogé l'outil à chacune des 43 questions corrigées. Vérifier fonctionne surtout : quatorze des 16 ont obtenu au moins 34 sur 43 avec l'outil là où personne n'a dépassé 23 de mémoire, et Claude Haiku 4.5, dont l'horloge date de 2022, a obtenu les 43 sans jamais répondre contre la base. Mais vérifier n'est pas croire. Sur la question qui ouvre ce billet, avec la base à un appel de distance, 8 des 16 ont quand même répondu 11 h, et deux d'entre eux ont écrit les bons décalages dans la même phrase. La note de GPT-5.6 Terra dit elle-même que Calgary était à -06:00 et Toronto à -05:00. Sa réponse était 11 h.

Une grille de 16 modèles répondant à la question de savoir ce que 9 h à Calgary donne à Toronto, avec l'outil tzdata disponible, huit affichant 10 h en vert et huit affichant 11 h en orange.
La même question, avec la base à un appel de distance. La moitié des modèles se sont quand même trompés, et sur les 16 il y a eu 47 réponses où le modèle a interrogé le bon endroit à la bonne date puis a répondu autre chose.

Claude Opus 5 a carrément contesté l'outil. Sur le décalage de Calgary, il a écrit que l'outil rapporte -06:00 avec l'abréviation CST, ce qui ne correspond pas aux règles réelles de l'Alberta, avant de se ranger à la réponse de l'outil. Sur Casablanca en décembre, il ne s'est pas rangé : il a répondu +01:00 en notant que la consultation avait renvoyé +00:00, ce qui entre en conflit avec cette règle connue. Gemini 3.5 Flash-Lite a appelé l'outil trois fois au sujet des horloges de Calgary le 1er novembre, s'est fait dire qu'elles ne changent pas, et a répondu qu'elles reculent. Mon échec préféré, c'est Coyhaique : la région chilienne d'Aysén a obtenu son propre fuseau dans tzdata 2025b, donc un modèle dont l'horloge s'est arrêtée avant ne sait pas que le fuseau existe, interroge la base au sujet de Santiago, obtient une réponse vraie sur le mauvais endroit, et la rapporte. Neuf des 16 ont raté cette question et seulement cinq ont interrogé le bon fuseau. Un outil de consultation corrige ce que le modèle sait aller consulter.

Une citation de Claude Opus 5 après avoir appelé l'outil au sujet de Calgary, indiquant que l'outil rapporte moins 06:00 avec l'abréviation CST, ce qui ne correspond pas aux règles réelles de l'Alberta.
Un modèle qui dit à la base de fuseaux horaires qu'elle se trompe sur l'Alberta. Sur ce coup-là il s'est rangé. Sur Casablanca, non.

Le Manitoba, que la base a fini par rattraper

Le Manitoba a annoncé le 17 septembre qu'il ne reculerait pas ses horloges le 1er novembre. Quand j'ai bâti le corrigé, aucune version ne le portait, donc ses trois questions ont été posées, consignées et laissées hors du score. Puis le 30 septembre, les mainteneurs ont publié tzdata 2026e avec le Manitoba dedans. J'ai donc corrigé ces trois réponses contre 2026e séparément. Winnipeg à midi le 15 novembre, c'est -05:00, et 9 h à Winnipeg, c'est 9 h à Toronto. Les 19 modèles ont dit -06:00 et les 19 ont dit 10 h. À la question de savoir si les horloges de Winnipeg changent le 1er novembre, 18 ont dit qu'elles reculent, et celui qui a dit le contraire n'y est arrivé qu'en croyant que le recul a lieu le 2 novembre. Le banc d'essai est passé avant que la base le sache, et la base a rattrapé neuf jours plus tard. Les modèles, eux, attendront un entraînement.

La page du banc d'essai World Clock sur Kaggle, montrant sa description, un classement sur deux tâches et 19 modèles, et un graphique du score en fonction du coût total.
Le banc d'essai est public sur Kaggle en deux tâches, de mémoire et avec l'outil tzdata. N'importe qui peut y passer un nouveau modèle sur les mêmes 125 questions, et le corrigé se met à jour tout seul à chaque version publiée par les mainteneurs.

Ce qui n'est pas revendiqué

La datation n'est pas exacte pour chaque modèle. Un modèle qui s'accorde avec sa version sommet sur 46 des 46 réponses modifiées a une horloge nette et la date est un fait sur ses réponses ; un modèle à 34 sur 46 a une horloge floue et la date est un meilleur ajustement, c'est pourquoi le tableau publie les deux chiffres pour chaque modèle. J'ai aussi corrigé le harnais plusieurs fois en chemin, donc 15 modèles ont passé la moitié de mémoire au moins deux fois, 42 passages en tout : le score du modèle médian a bougé de 2 questions entre les passages, le plus grand écart a été de 10, et la version datée a tenu dans 10 cas sur 15. Chaque passage de chaque modèle plaçait encore Calgary à -07:00. Les trois questions sur le Manitoba sont exclues du score principal par construction et rapportées à part. GLM-5 et DeepSeek-R1 ont chacun perdu un appel vers leur serveur et sont notés sur 121 plutôt que 122, et Gemma 4 a laissé six réponses vides, qui comptent comme fausses. La moitié avec outil porte sur 46 questions et non sur l'ensemble, parce que Kaggle accorde 10 $ de quota de modèle par jour et qu'une boucle d'outil coûte plusieurs fois une réponse simple ; ma première série complète l'a vidé et chaque passage en file a échoué sur un 403. GPT-6 Astra est absent de cette moitié parce que son API refuse les outils de fonction si le raisonnement n'est pas désactivé et refuse de le désactiver, et trois modèles listés par le proxy ne peuvent pas être servis du tout, ce que je rapporte au lieu de les retirer en silence. Enfin, tout ceci mesure un type de connaissance très étroit. Ça ne dit rien sur la qualité d'un modèle, seulement sur le mois où son horloge du monde s'est arrêtée.

Projet associé

World Clock: a Kaggle benchmark that asks 19 frontier models what time it is, grades every answer against the IANA tz database, and dates each model's clock to the month it stopped

Voir le projet