Öffentliche URLs, die in der IANA-Zeitzonen-Datenbank zitiert werden: Eine Übersicht über abgebrochene Links.

Die IANA Time Zone Database kodiert, wie die örtlichen Uhren auf der Welt angepasst werden. Weniger offensichtlich ist, dass ihre Kommentarblöcke auch angeben, woher diese Regeln stammen. Der ursprüngliche Quellcode befindet sich unter https://github.com/eggert/tz.

Eine Untersuchung dieser Verweise stellte eine praktische Frage: Von den in den Kommentaren aufgeführten öffentlichen URLs – wie viele funktionieren noch heute? Jeder solche URL wurde gesammelt, getestet und bei Bedarf wiederhergestellt – zunächst über einen Entsperrungs-Proxy, der gängige Bot-Blockaden umgeht, anschließend über die Wayback API, falls der aktuelle Host nicht mehr erreichbar war. Code, Tabellen zur Untersuchung sowie der Ablauf für die Wiederherstellung von 1.327 URLs sind unter https://github.com/sixthextinction/tzdata-citation-census veröffentlicht.

Das „Kaninchenloch“ entstand durch eine Notiz aus dem Jahr 2008 des Freiwilligen Patrice Scattolin. Er rekonstruierte den genauen Zeitpunkt des Beginns der Sommerzeitumstellung in Marokko im Jahr 2008 (Hintergrund: https://en.wikipedia.org/wiki/Daylight_saving_time_in_Morocco), las einen zeitgenössischen Bericht unter https://www.avmaroc.com/actualite/heure-dete-comment-a127896.html und hatte Schwierigkeiten mit einer Mehrdeutigkeit im Französischen. Die von ihm hinterlassene Notiz ist typisch für dieses Korpus: Sie nennt das Dekret 2–08–224 und gibt zu, dass der offizielle Text zu diesem Zeitpunkt nicht online auffindbar war.

Historische Datenbanken sind voller solcher Notizen – Dekretnummern, Amtsblätter, URLs von Zeitungen, Daten sowie Erklärungen dafür, warum eine Quelle der anderen vorgezogen wurde. Die größere Frage ist, wie viele dieser öffentlichen URLs nach Jahren weiterhin funktionieren.

Was ist tzdata eigentlich?

Die IANA Time Zone Database ist eine Sammlung von Textdateien, die von Mitwirkenden gepflegt werden. Betriebssysteme und Sprachlaufzeiten wenden sich an sie, wenn sie die Ortszeit für einen bestimmten Zeitzone-Bereich benötigen. Endbenutzer öffnen diese Dateien nur selten, doch fast jede Linux-Distribution sowie jeder Programmierlaufzeitumfang enthält sie. Sobald ein Staat seine Uhren anpasst, muss die Datensammlung aktualisiert werden, andernfalls geben alle abhängigen Anwendungen die falsche Ortszeit an.

Mitwirkende können bei der Vorschlag von Korrekturen den in https://data.iana.org/time-zones/tz-how-to.html verfügbaren Korrekturleitfaden nutzen.

Die Regeln selbst können sehr knapp formuliert sein. Die Änderung der Sommerzeit in Marokko im Jahr 2008 besteht beispielsweise aus zwei Zeilen in der africa-Datei:

# 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 -

Diese Zeilen definieren die Umstellungen am 1. Juni und 1. September, die Maschinen weltweit befolgen müssen.

Die umliegenden Kommentare enthalten die Geschichte der Erstellung. Die Betreuer dokumentieren Beweise: Dekretnummern, Regierungsblätter, Mitteilungen von Ministerien, Zeitungsartikel oder die Person, die einen Hinweis gegeben hat – meist zusammen mit dem Datum, an dem die Notiz hinzugefügt wurde.

Manchmal stimmen die Quellen nicht überein. Die Betreuer dokumentieren gelegentlich den Konflikt und geben an, welcher Seite sie vertrauen. Im Jahr 2006 verwies Paul Eggert die Daten aus Atlanten zugunsten des österreichischen Nationalamts für Metrologie (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.

Ob diese Quellenkultur von Anfang an geplant war oder sich organisch entwickelt hat, ist unklar. Auf jeden Fall hinterlässt sie eine nutzbare Nachverfolgungsliste für Entscheidungen, die über mehr als dreißig Jahre gemeinsamer Pflege getroffen wurden – insbesondere dann, wenn die Beweise spärlich oder widersprüchlich sind.

Was passiert also, wenn man tatsächlich die Zitate überprüft?

Jeder URL wurde aus Kommentarblöcken in den neun Quelldateien von tzdata extrahiert. Dabei wurden 1609 Kommentarblöcke gefunden, die insgesamt 1352 URL-Erwähnungen enthielten, was auf 1327 unterschiedliche Adressen bei 623 Hosts reduziert wurde. Blöcke, die nur Bücher, Verordnungen oder E-Mails ohne URL erwähnten, fielen außerhalb des Untersuchungsbereichs.

Jede Adresse wurde mit einem normalen HTTP GET-Anfragen, einem herkömmlichen Browser-Identity-Header (wie in MDNs User-Agent-Dokumentation beschrieben) sowie einer festgelegten Timeout-Frist überprüft, damit blockierte Hosts die Erhebung nicht verzögern konnten.

Diese erste Überprüfung ergab nutzbare Inhalte für 663 URLs. Die anderen 664 URLs scheiterten aus verschiedenen Gründen, weshalb sie sorgfältig klassifiziert wurden: Ein 404-Fehler ist nicht dasselbe wie eine aktive Seite, die Automatisierungen ablehnt.

Zu den Fehlern:

• 433 konnten nicht direkt abgerufen werden, funktionierten aber über einen Proxy. 178 lehnten die direkte Anfrage ab (meist HTTP 403, teilweise 429). Weitere 255 scheiterten im Heimnetzwerk aufgrund von DNS-, Zeitüberschreiten- oder TLS-Fehlern, anstatt durch eine explizite Blockierung von Bots. Beide Gruppen wurden mit Bright Data’s Web Unlocker erneut versucht und wiederhergestellt.
• 123 waren tatsächlich verschwunden. Sie gaben HTTP 404 oder 410 zurück. Nach Überprüfung mit dem Internet Archive’s Wayback Machine lieferte alle außer zwei eine vollständige archivierte Kopie – 121 konnten wiederhergestellt werden.
• 108 blieben ungelöst (57 ohne Archivfund, 39 scheiterten weiterhin mit dem Unlocker und 12 gaben HTTP 500 zurück). Achtzehn der ungelösten Fälle, alle auf Mexikos dof.gob.mx-Portal, zeigten Zertifikatsfehler – vermutlich eine Fehlkonfiguration des Hosts statt einer gelöschten Seite, lagen aber außerhalb der Reichweite der Volkszählung.

Eine verschwundene Seite ist ein Versagen bei der Erhaltung. Eine aktive Seite, die automatisierte GET-Anfragen ablehnt, ist ein Zugriffsversagen. Beides verhindert einen naiven Crawling-Vorgang; sie deuten unterschiedliche Dinge darauf hin, ob die Quellen noch vorhanden sind.

Aus Zahlen allein lässt sich die tatsächliche Funktionsweise nicht ableiten. Zu den 663 direkten Erfolgen gehören Regierungsportale, Zeitungsarchive sowie persönliche Seiten, die auch heute noch Antworten liefern. Die 433 über Proxy wiederhergestellten Seiten zeigen, wie oft „kaputte“ Verweise in Wirklichkeit auf Anti-Automatisierungs-Politiken zurückzuführen sind. Die 121 Wayback-Backups zeigen, wie oft das Internet Archive bereits ein nutzbares Abbild bereitgestellt hat – mit Ausnahme von zwei Fällen mit 404/410-Fehlern, bei denen selbst das Archiv leer war. Genau diese Trennung macht die Statistiken für alle, die die Messung später wiederholen, interpretierbar.

Warum wird eine Quelle überhaupt blockiert?

Die meisten Websites behandeln heutzutage skriptbasierte Clients anders als herkömmliche Browser. Anfragen, die JavaScript überspringen oder bei Browser-Fingerprint-Prüfungen versagen, können begrenzt werden, abgelehnt oder angefochten.

Das erschwert die Massenüberprüfung alter Zitate. Eine URL, die funktioniert hat, als ein Betreuer sie eingefügt hat, könnte zwar noch aktiv sein, aber Jahre später eine einfache automatisierte Anfrage ablehnen.

Offizielle Gesetzessammlungen und Rechtsdatenbanken kommen im Korpus häufig vor – wie dre.pt in Portugal, resmigazete.gov.tr in der Türkei, der Rechtsberichterstatter nevo.co.il in Israel sowie ähnliche Plattformen. Die Betreuer haben sie intensiv wiederverwendet, und einige dieser Seiten konnten dennoch nicht direkt abgerufen werden.

Eine fehlgeschlagene Anfrage beweist daher nicht unbedingt ein Verschwinden. Es könnte bedeuten, dass die Seite entfernt wurde, oder dass die Abrufmethode nicht mehr erwünscht ist. Der Wiederherstellungsprozess hat solche Fälle als separate Kategorien behandelt.

Ist das wirklich ein tzdata-Problem?

Nicht in erster Linie. Das Experiment misst, wie gut externe Quellen, die in einem langfristig vorhandenen historischen Datensatz aufgezeichnet sind, überlebt haben.

tzdata kann das von ihm zitierte Material nicht bewahren. Die Regeln befinden sich in einem versionierten System und werden weltweit innerhalb von Betriebssystemen bereitgestellt, doch die zitierten Seiten bleiben auf unabhängigen Webseiten, Regierungsportalen und Zeitungssammlungen.

Zugriffsprobleme sind nichts Neues. Schon eine Mitteilung aus Ägypten aus dem Jahr 2014 über die Sommerzeit erwähnte, dass die Seite mit der Ankündigung des Kabinetts (http://www.cabinet.gov.eg/Media/CabinetMeetingsDetails.aspx?id=347) aus dem Ausland nicht geladen werden konnte. Probleme mit geofenced Daten gab es bereits lange vor dieser Erhebung.

Wie sah der Wiederherstellungsprozess tatsächlich aus?

Die Wiederherstellung fand in getrennten Schritten statt, damit die Fehlerarten voneinander getrennt blieben.

Das Ausprobieren jeder Methode bei jeder URL – direkt, über Proxy und dann über Archiv – würde die Anzahl der „wiederhergestellten“ Seiten erhöhen, während gleichzeitig die Kategorisierung unklar wird. Ein 404-Fehler unterscheidet sich von einem vorübergehenden Blockieren. Auch ein Archiv-Snapshot ist nicht identisch mit der Seite, die der Betreuer gelesen hat; es handelt sich dabei um eine Aufnahme zu einem früheren oder späteren Zeitpunkt.

Eine weitere Kategorie umfasste ausschließlich direkte Anfragen, bei denen der genaue HTTP-Status aufgezeichnet wurde. URLs, die 404 oder 410 zurückgaben, wurden einer separaten, mit einer Bandbreitenbeschränkung versehenen Abfrage gegen die Internet Archive Availability API zugeordnet. URLs, bei denen eine Zeitüberschreitung oder ein Blockieren auftrat, wurden in dieser Phase nicht an das Archiv gesendet.

Konzeptionell:

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" };
}

Der Proxy-Modus war eine weitere Stufe. Er richtete sich auf URLs, die der direkte Modus aufgrund von Blockaden oder Zugriffsproblemen nicht abrufen konnte – und zwar nicht auf URLs, die bereits 404 oder 410 angezeigt hatten. Geblockte URLs wurden als gewöhnliche GET-Anfragen über Bright Data’s Web Unlocker versucht, der als natives HTTPS-Proxy fungierte:

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",
});

Der genannte Pfad ist nicht das vom Browser gerenderte Ergebnis – es handelt sich lediglich um eine über den Unlocker geleitete HTTP-Anfrage. Anmeldeinformationen sollten in einer .env-Datei gespeichert werden:

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

Durch getrennte Verarbeitungswege kann die endgültige Tabelle direkte Abfragen, durch den Proxy wiederhergestellte Daten, aus Archiven wiederhergestellte Daten sowie ungelöste Verweise unterscheiden.

Methodisch ist der Unlocker-Pass wichtig, weil er zwischen „die Seite existiert weiterhin hinter einer Herausforderung“ und „die Seite ist verschwunden“ unterscheidet. Ohne diese Unterscheidung würde ein naiver Crawler Fehlinformationen über fehlerhafte Links erzeugen. Ebenso verhindert das Senden nur von 404/410-Antworten an Wayback, dass die Archive-API mit Hosts überflutet wird, die lediglich Bots blockierten – was die Wiederherstellungsstatistiken verfälscht und bei weniger wichtigen Anfragen die Rate-Limits ausreizt.

Was können Sie mit den Quellen anfangen, sobald Sie sie haben?

Hier ging es um die Verfügbarkeit: Kann die angegebene URL weiterhin abgerufen werden, und falls nicht, kann das Dokument an anderer Stelle wiederhergestellt werden?

Für ein historisches Datensatz muss außerdem der Inhalt der wiederhergestellten Seite selbst erhalten bleiben. Bei einer Zeitung oder einer Rechtsdatenbank bedeutet das in der Regel die Extraktion der Verordnungsnummer, des Datums, des Titels sowie des relevanten Textes und die Speicherung dieser Felder neben der ursprünglichen Quellenangabe. So bleiben die Beweise erhalten, selbst wenn die URL später nicht mehr erreichbar ist, ohne dass ein weiterer Crawling-Vorgang erforderlich wäre, um die Links erneut zu finden.

Mehrfach auftretende Hosts eignen sich besonders gut für die Automatisierung. Nach dem Entsperrung der Abrufmöglichkeiten kann ein strukturierter Sammler Felder definieren und auf derselben Infrastruktur arbeiten. Gewöhnliche HTTP-Seiten lassen sich mit einem auf Code ausgerichteten Worker verarbeiten; seitenintensiv nutzende JavaScript-Implementierungen erfordern hingegen einen Browser-Worker.

Was bleibt also tatsächlich übrig, wenn das Archiv es nicht hat?

Einhundertacht Verweis-URLs blieben ungelöst – etwa 8 Prozent von 1.327 einzigartigen URLs – was zwar einen geringen Anteil darstellt, aber dennoch eine Menge an nicht wiederherstellbaren Quellen bedeutet. Der Anteil ist zwar bescheiden, doch jede URL unterstützte einst eine konkrete Zeitzone-Regel.

Die Regeln befinden sich weiterhin in tzdata. Was fehlt, sind teilweise oder ganz die externen Seiten an diesen Adressen.

Von den 108 URLs gaben 57 die Fehlermeldungen 404 oder 410 aus, ohne dass es eine Wayback-Aufzeichnung gab. Neununddreißig URLs funktionierten weiterhin nicht über den Proxy (davon acht aufgrund von Zertifikatsfehlern aus Mexiko). Zwölf URLs erzeugten weitere HTTP-Fehler, die weder erneut versucht noch an Wayback gesendet wurden.

Eine exotischere Wiederherstellung war möglich, doch die Erhebung benötigte eine feste Beendigungsregel: Die Verweislandschaft sollte mit einem einheitlichen Verfahren gemessen werden, anstatt endlos nach einer immer kleiner werdenden Anzahl von Quellen zu suchen.

Die Grenzen der Verweise als Erhaltungsmittel

Historische Datensätze sowie die von ihnen zitierten Seiten weisen asymmetrische Erhaltungsmerkmale auf.

Eine Zeitzone-Regel wird im Versionskontrollsystem gespeichert und durch unzählige Softwareverteilungen weitergegeben. Sobald sie eingeführt wurde, kann sie länger bestehen als die Belege, die ihre Notwendigkeit begründet haben.

Zitiertes Material hat keine solche Garantie. Es kann unter einer URL bei einer Organisation vorhanden sein. Wenn diese Organisation umzieht, löscht, den Zugang einschränkt oder den Service aufgibt, wird das Zitat schwer oder unmöglich zugänglich. Dieses Versagen wird üblicherweise als „Link-Rot“ bezeichnet.

Die Betreiber von tzdata dokumentieren seit Jahrzehnten Quellen und weisen oft auf Unsicherheiten hin. Dadurch fällt spätere Recherche viel leichter als es ununterstützte Behauptungen zuließen. Sorgfältiges Zitieren sichert das zitierte Material dennoch nicht ab, und die Betreiber sind nicht verpflichtet, alles zu speichern, auf das sie verweisen.

Die Erhebung ist daher weniger eine Kritik an tzdata als vielmehr eine Demonstration dafür, inwieweit externe URLs als historische Referenzen vertrauenswürdig sind. Die meisten Zitate konnten in irgendeiner Form rekonstruiert werden. Eine kleinere, aber bedeutende Anzahl ließ sich hingegen nicht finden. Die Datenbank enthält weiterhin die von diesen Quellen festgelegten Regeln; in 108 Fällen kann sie die URL nicht mehr aufrufen.

Wenn die Erhebung ein Jahr später wiederholt würde, würden vermutlich einige URLs aufgrund von Änderungen bei TLS, CDN-Regeln oder Roboter-Richtlinien zwischen den Kategorien umgeordnet. Das Interessante Merkmal ist nicht ein in der Zeit erstarrter Prozentsatz, sondern wie schnell die Zitate von „direkt einsetzbar“ zu „braucht Proxy“ oder „nur aus Archiven verfügbar“ wechseln und wie viele in die ungelöste Restgruppe fallen, die keine automatisierte Lösung abdecken kann.

Für Anwender, die andere langfristig bestehende Datensätze pflegen – CLDR-Lokaldaten, Geoname-Dumps, gesetzliche Scraping-Dateien – gilt derselbe Messansatz. Erfassen Sie alle öffentlichen URLs in Kommentaren oder Herkunftsfeldern, klassifizieren Sie Fehler nach HTTP-Semantik, beheben Sie Probleme mithilfe eines Unlockers nur dann, wenn es sich um Zugriffsrichtlinien handelt, und wenden Sie sich an ein Archiv nur dann, wenn der Ursprung angibt, dass die Ressource nicht mehr vorhanden ist. Veröffentlichen Sie die Zählungen der Bucket neben der Liste der Roh-URLs, damit spätere Leser denselben Vorgang erneut durchführen können, anstatt sich auf einen einzigen prozentualen Wert zu verlassen.