URL publiques citées par la base de données des zones horaires IANA : un recensement des liens morts

La base de données des zones horaires d’IANA décrit la manière dont les horloges locales évoluent dans le monde entier. De manière moins évidente, ses blocs de commentaires indiquent également d’où proviennent ces règles. L’arbre source se trouve à l’adresse https://github.com/eggert/tz.

Un recensement de ces citations a soulevé une question pratique : parmi les URLs publiques mentionnées dans les commentaires, combien fonctionnent encore aujourd’hui ? Chacune de ces URLs a été collectée, testée et, le cas échéant, récupérée, d’abord à l’aide d’un proxy de déverrouillage permettant de contourner les blocages courants des bots, puis via l’API Wayback lorsque le site en ligne n’était plus accessible. Le code, les tableaux de recensement ainsi que le processus de récupération pour 1 327 URLs sont publiés à l’adresse https://github.com/sixthextinction/tzdata-citation-census.

Le « trou de lapin » a vu le jour grâce à une note de 2008 rédigée par le bénévole Patrice Scattolin. Il tentait de reconstituer le moment exact où le Maroc a mis en place le changement d’heure en 2008 (contexte : https://en.wikipedia.org/wiki/Daylight_saving_time_in_Morocco), en consultant un rapport de l’époque à l’adresse https://www.avmaroc.com/actualite/heure-dete-comment-a127896.html, tout en se débattant avec une ambiguïté entre le français et l’anglais. La note qu’il a laissée est typique de ce corpus : elle mentionne le décret 2–08–224 et admet que le texte officiel n’était pas disponible en ligne à l’époque.

Les bases de données historiques regorgent de notes de ce type — numéros de décrets, publications officielles, adresses URL de journaux, dates, ainsi que des explications sur les raisons pour lesquelles une source l’a emporté sur une autre. La question plus large est de savoir combien de ces URLs publiques fonctionnent encore après des années d’évolution.

Qu’est-ce que tzdata, au juste ?

La base de données des zones horaires IANA est un ensemble de fichiers texte gérés par des contributeurs. Les systèmes d’exploitation et les environnements de programmation y consultent leurs informations lorsqu’ils ont besoin de l’heure légale pour une zone donnée. Les utilisateurs finaux ouvrent rarement ces fichiers, mais presque toutes les distributions Linux et tous les environnements de programmation les incluent. Chaque fois qu’une juridiction modifie son heure d’été, la base de données doit être mise à jour, sinon toutes les applications qui s’y réfèrent afficheront l’heure locale incorrecte.

Les contributeurs peuvent suivre le guide de correction disponible à l’adresse https://data.iana.org/time-zones/tz-how-to.html lorsqu’ils proposent des corrections.

Les règles elles-mêmes peuvent être très succinctes. La modification concernant l’heure d’été au Maroc en 2008 se limite à deux lignes de texte brut dans le fichier africa :

# Rule NAME FROM TO - IN ON AT SAVE LETTER/S
Rule Morocco 2008 only - Jun 1 0:00 1:00 -
Rule Morocco 2008 only - Sep 1 0:00 0 -

Ces lignes définissent les transitions du 1er juin et du 1er septembre que tous les ordinateurs dans le monde doivent respecter.

Les commentaires qui l’entourent contiennent l’histoire de la création. Les responsables enregistrent des preuves : numéros de décrets, publications officielles, communiqués ministériels, articles de presse, ou encore l’identité de la personne qui a fourni une information, généralement accompagnés de la date à laquelle la note a été ajoutée.

Les sources peuvent parfois être en désaccord. Les responsables documentent occasionnellement ce conflit et indiquent de quel côté ils se fient. En 2006, Paul Eggert a écarté les dates figurant dans l’atlas au profit du bureau national de métrologie autrichien (https://www.bev.gv.at/) :

# From Paul Eggert (2006-03-22): Shanks & Pottenger give 1918-06-16 and
# 1945-11-18, but the Austrian Federal Office of Metrology and
# Surveying (BEV) gives 1918-09-16 and for Vienna gives the "alleged"
# date of 1945-04-12 with no time. For the 1980-04-06 transition
# Shanks & Pottenger give 02:00, the BEV 00:00. Go with the BEV,
# and guess 02:00 for 1945-04-12.

Il n’est pas clair si cette culture de référencement a été conçue dès le début ou s’est développée naturellement. Quoi qu’il en soit, elle permet de disposer d’un historique fiable des décisions prises au cours de plus de trente ans de maintenance commune, surtout lorsque les preuves sont insuffisantes ou contradictoires.

Que se passe-t-il lorsque l’on va vérifier les citations ?

Chaque URL a été extraite des blocs de commentaires présents dans les neuf fichiers sources tzdata. Cette première étape a révélé mille six cent neuf blocs de commentaires contenant mille trois cent cinquante-deux mentions d’URL, ce qui correspond à mille trois cent vingt-sept adresses distinctes sur six cent vingt-trois hôtes. Les blocs ne citant que des livres, des décrets ou du courrier sans URL étaient exclus de l’étude.

Chaque adresse a été testée à l’aide d’une requête HTTP GET ordinaire, d’en-têtes d’identité de navigateur conventionnels (comme décrit dans la documentation MDN sur User-Agent), ainsi que d’un délai d’attente strict afin que les hôtes en panne ne ralentissent pas le processus d’inventaire.

Cette première étape a permis d’obtenir des contenus utilisables pour 663 URLs. Les 664 autres ont échoué pour diverses raisons, et ont donc été classées avec soin : un code 404 n’est pas identique à une page active qui refuse l’automatisation.

Parmi les échecs :

• 433 n’ont pas pu être récupérés directement, mais ont fonctionné via un proxy. 178 ont rejeté la demande directe (principalement des erreurs HTTP 403, quelques-unes 429). Une autre centaine (255) a échoué en raison de problèmes de réseau domestique, de DNS, de délais d’attente ou d’erreurs TLS, et non pas à cause d’un blocage explicite des bots. Les deux groupes ont été réessayés à l’aide de Bright Data’s Web Unlocker et ont pu être récupérés.
• 123 étaient véritablement introuvables. Ils renvoyaient des erreurs HTTP 404 ou 410. Après vérification via la Wayback Machine de l’Internet Archive, tous sauf deux présentaient une copie complète archivée — 121 ont pu être récupérés.
• 108 sont restés non résolus (57 sans archive trouvée, 39 qui continuaient d’échouer avec l’outil de déverrouillage, et 12 renvoyant des erreurs HTTP 500). Parmi ces non résolus, dix-huit sites appartenant au portail mexicain dof.gob.mx présentaient des erreurs de certificat — probablement due à une mauvaise configuration du serveur plutôt qu’à la suppression d’une page, mais hors de portée du recensement.

Un site disparu représente un échec de la conservation. Un site actif qui refuse les requêtes GET automatisées constitue un échec d’accès. Tous deux empêchent un balayage naïf ; ils indiquent des choses différentes quant à la présence éventuelle des données originales.

Les chiffres seuls ne racontent pas l’histoire opérationnelle. Les 663 succès directs comprennent des portails gouvernementaux, des archives de journaux et des pages personnelles qui fonctionnent encore aujourd’hui. Les 433 récupérations via des proxys montrent à quelle fréquence les citations « cassées » sont en réalité le résultat de politiques anti-automatisation. Les 121 cas remplis par Wayback montrent à quelle fréquence l’Internet Archive disposait déjà d’une capture utilisable — à l’exception de deux cas 404/410 où même l’archive était vide. C’est en gardant ces catégories séparées que le recensement reste interprétable pour quiconque effectue cette mesure ultérieurement.

Pourquoi une citation serait-elle bloquée en premier lieu ?

La plupart des sites traitent aujourd’hui les clients scriptés différemment des navigateurs ordinaires. Les requêtes qui ignorent JavaScript ou échouent aux vérifications de fingerprinting du navigateur peuvent faire l’objet de limitations de fréquence, être rejetées ou remises en question.

Cela complique la vérification en masse des citations anciennes. Une URL qui fonctionnait lorsque son administrateur l’a insérée peut encore être active, mais refuser une simple requête automatisée des années plus tard.

Les journaux officiels et les bases de données juridiques apparaissent fréquemment dans le corpus : dre.pt au Portugal, resmigazete.gov.tr en Turquie, le service d’actualités juridiques nevo.co.il en Israël, ainsi que d’autres sites similaires. Leurs administrateurs les ont largement réutilisés, et certaines de ces pages ne peuvent toujours pas être consultées directement.

Ainsi, une requête infructueuse ne prouve pas la disparition d’un contenu. Cela peut signifier son suppression, ou bien que la méthode de récupération n’est plus acceptée. Le processus de récupération traitait ces cas comme des catégories distinctes.

S’agit-il vraiment d’un problème tzdata ?

Pas principalement. L’expérience mesure dans quelle mesure les sources externes enregistrées dans un ensemble de données historiques de longue durée ont survécu.

tzdata ne peut pas conserver le matériel qu’il cite. Les règles se trouvent dans un arbre contrôlé par version et sont intégrées dans les systèmes d’exploitation partout dans le monde, mais les pages citées restent sur des sites web indépendants, des portails gouvernementaux et des archives de journaux.

Les problèmes d’accès ne sont pas nouveaux. Une note égyptienne de 2014 sur l’heure d’été indiquait déjà que la page d’annonce du cabinet (http://www.cabinet.gov.eg/Media/CabinetMeetingsDetails.aspx?id=347) ne pouvait pas être chargée depuis l’extérieur du pays. Les problèmes liés aux restrictions géographiques existaient déjà bien avant ce recensement.

À quoi ressemblait réellement le processus de récupération ?

La récupération s’est déroulée en plusieurs étapes séparées afin que les modes de défaillance restent distincts.

Tenter chaque méthode sur chaque URL — directe, puis via un proxy, puis en utilisant une archive — augmenterait le nombre de pages « récupérées » tout en embrouillant les catégories. Une erreur 404 diffère d’un blocage temporaire. Un instantané d’archive n’est pas non plus identique à la page lue par le responsable de maintenance ; il s’agit d’une capture prise à un moment antérieur ou postérieur.

Une étape distincte était réservée uniquement aux requêtes directes, permettant d’enregistrer l’état HTTP exact. Les URLs renvoyant 404 ou 410 étaient traitées dans une autre étape, soumise à des limitations de fréquence, en utilisant l’API d’disponibilité d’Internet Archive. Les URLs ayant expiré ou été bloquées n’étaient pas envoyées à l’archive à ce stade.

Conceptuellement :

async function checkCitation(url) {
  const direct = await get(url); // one plain GET, no tricks
  if (isOk(direct)) return { status: "live", via: "direct" };

  if (direct.status === 404 || direct.status === 410) {
    const archived = await wayback(url); // only for confirmed-dead
    if (archived.hit) return { status: "recovered", via: "wayback" };
  }

  return { status: "unresolved" };
}

Le mode de transmission par proxy représentait une étape supplémentaire. Il ciblait les URL que la transmission directe ne pouvait pas récupérer en raison de blocages ou de problèmes d’accessibilité, et non les URL qui avaient déjà renvoyé des codes 404 ou 410. Les URL bloquées étaient réessayées sous forme de requêtes GET ordinaires via Bright Data’s Web Unlocker, qui agissait comme un proxy HTTPS natif :

import { ProxyAgent, fetch as proxyFetch } from "undici";

const AUTH = process.env.BRIGHT_DATA_UNLOCKER_AUTH; // format like USER:PASS

const dispatcher = new ProxyAgent({
  uri: `@brd.superproxy.io:44445`">http://${AUTH}@brd.superproxy.io:44445`,
  requestTls: { rejectUnauthorized: false },
  proxyTls: { rejectUnauthorized: false },
});

const res = await proxyFetch(url, {
  dispatcher,
  headers: { "User-Agent": UA, Accept: "*/*" },
  redirect: "follow",
});

Ce chemin n’est pas le résultat affiché par le navigateur — il s’agit simplement d’une requête HTTP acheminée via l’outil de déverrouillage. Les identifiants doivent être stockés dans le fichier .env :

BRIGHT_DATA_UNLOCKER_AUTH=brd-customer-XXXXX-zone-web_unlocker:PASSWORD
BRIGHT_DATA_UNLOCKER_PROXY_HOST=brd.superproxy.io
BRIGHT_DATA_UNLOCKER_PROXY_PORT=44445

Des modes de transmission séparés permettent au tableau final de distinguer les accès directs, les récupérations via proxy, les récupérations depuis des archives, ainsi que les citations non résolues.

D’un point de vue méthodologique, le passe déverrouillage est important car il distingue « la page existe toujours derrière un défi » de « la page a disparu ». Sans cette distinction, un moteur de parcours naïf compterait à tort trop d’erreurs de lien. De même, en ne renvoyant que des réponses 404/410 à Wayback, on évite de submerger l’API d’archivage avec des hébergeurs qui bloquaient simplement les bots, ce qui aurait embrouillé les statistiques de récupération et épuisé les limites de fréquence pour des requêtes peu importantes.

Que pouvez-vous faire avec ces sources une fois que vous les avez obtenues ?

Ici, la question est l’accessibilité : le URL cité peut-il encore être récupéré, et si ce n’est pas le cas, le document peut-il être retrouvé ailleurs ?

Pour un ensemble de données historiques, une étape supplémentaire consiste à conserver le contenu de la page récupérée elle-même. Pour une gazette ou une base de données juridique, cela peut signifier extraire le numéro du décret, la date, le titre et le texte pertinent, puis stocker ces champs à côté de la citation originale. Ainsi, les preuves restent accessibles même si l’URL devient inutilisable par la suite, sans avoir besoin d’un nouvel indexage uniquement pour retrouver les liens.

Les hôtes récurrents conviennent particulièrement à l’automatisation. Une fois les requêtes débloquées, un collecteur structuré peut définir des champs et fonctionner sur la même infrastructure. Les pages HTTP ordinaires s’adaptent à un processus orienté code ; les pages riches en JavaScript nécessitent quant à elles un processus dans le navigateur.

Que reste-t-il réellement lorsque l’archive ne le possède pas ?

Cent huit URL de citation sont restées non résolues — environ 8 pour cent des 1 327 URL uniques — une proportion modeste en apparence, mais qui représente un ensemble important de sources dont l’origine ne peut être retrouvée. Bien que cette proportion soit faible, chaque URL correspondait autrefois à une règle précise de fuseau horaire.

Ces règles se trouvent toujours dans tzdata. Ce qui manque, c’est une partie ou la totalité de la page externe située à cette adresse.

Sur ces 108 URL, 57 ont renvoyé des erreurs 404 ou 410 sans aucun enregistrement de disponibilité sur Wayback. Trente-neuf ont continué à échouer via le proxy (dix-huit d’entre elles étant dues à des erreurs de certificat au Mexique). Douze ont généré d’autres erreurs HTTP qui n’ont ni été réessayées ni envoyées à Wayback.

Des méthodes de récupération plus complexes auraient pu être utilisées, mais le recensement nécessitait une règle d’arrêt fixe : mesurer l’ensemble des citations selon une procédure cohérente plutôt que de poursuivre indéfiniment la recherche d’un nombre toujours plus réduit de sources.

Les limites des citations en tant que méthode de conservation

Les ensembles de données historiques et les pages qu’ils citent présentent des propriétés de conservation asymétriques.

Une règle de fuseau horaire est stockée dans le système de contrôle de version et se propage à travers d’innombrables distributions logicielles. Une fois intégrée, cette règle peut survivre au-delà des preuves qui la justifiaient à l’origine.

Le matériel cité ne bénéficie pas de telle garantie. Il peut exister sous une seule URL au sein d’une seule organisation. Si cette organisation déménage, supprime, modifie les accès ou abandonne le service, il devient difficile voire impossible de retrouver la citation. Ce type de défaillance est communément appelé « link rot ».

Les responsables de tzdata enregistrent les sources depuis des décennies et indiquent souvent leur incertitude. Cela rend les recherches ultérieures bien plus faciles que ne le permettraient des affirmations non étayées. Une citation soignée ne constitue toutefois pas d’archive de l’élément cité, et les responsables ne sont pas tenus de mettre en cache tout ce à quoi ils font référence.

Le recensement est donc moins une critique de tzdata qu’une démonstration du degré de fiabilité des URL externes en tant que références historiques. La plupart des citations pouvaient être retrouvées sous une forme ou une autre. Un nombre plus petit, mais significatif, ne le pouvait pas. La base de données conserve toujours les règles établies par ces sources ; dans 108 cas, elle ne parvient plus à récupérer l’URL.

Répéter le recensement un an plus tard provoquerait probablement des déplacements de certaines URL entre les catégories, car les sites modifient leurs paramètres TLS, leurs règles CDN ou leurs politiques robots. Le signal intéressant n’est pas un pourcentage fixé dans le temps ; il s’agit de la vitesse à laquelle les citations passent d’un statut « directement acceptable » à « nécessite un proxy » ou « uniquement disponible en archive », ainsi que du nombre de celles qui restent dans la catégorie non résolue, impossible à traiter automatiquement.

Pour ceux qui gèrent d’autres ensembles de données à long terme — données locales CLDR, fichiers geoname, outils de scraping législatif — la même méthode de mesure s’applique. Faites une liste de tous les URL publics dans les commentaires ou les champs de provenance, classez les échecs selon la sémantique HTTP, utilisez un outil de déverrouillage uniquement lorsque l’échec semble lié à une politique d’accès, et consultez un archive uniquement lorsque l’origine indique que la ressource a disparu. Publiez les comptes des buckets à côté de la liste des URL brutes afin que les lecteurs ultérieurs puissent répéter la même procédure au lieu de se fier à un pourcentage unique présenté dans un titre.