"Australia/Lord_Howe" ist die seltsamste Zeitzone

• Zeitzonen sind komplex, aber weil Computer sie implementieren müssen, sind sie nur innerhalb eines endlichen Rahmens seltsam.
  • Asia/Kathmandu hat einen ungewöhnlichen Offset zu UTC.
  • Africa/Casablanca passt nicht gut in das Zeitzonenmodell und wird deshalb hartkodiert.
  • America/Nuuk beginnt die Sommerzeit bei -01:00.
  • Africa/Cairo und America/Santiago beginnen die Sommerzeit um 24 Uhr (nicht um 0 Uhr).
  • Australia/Lord_Howe hat die seltsamsten Sommerzeitregeln.

PGXIIREAM: Papst Gregor XIII. beherrscht alles

• Der größte Teil der Welt verwendet ein Zeitsystem auf Basis des gregorianischen Kalenders.
• Der gregorianische Kalender ist sehr nützlich, um die Position der Sonne im Jahresverlauf konstant zu halten.
• UTC ist die moderne formale Ausprägung des gregorianischen Kalenders, und die ganze Welt richtet ihre Zeit danach aus.

Schaltsekunden sind nicht wichtig

• Die Erdrotation verlangsamt sich, daher werden Schaltsekunden hinzugefügt, um das zu korrigieren.
• Schaltsekunden kann man ignorieren, weil Programmiersprachen keine 61 Sekunden darstellen.
• Cloud-Anbieter lösen das Problem, indem sie ihre Uhren während einer Schaltsekunde langsamer laufen lassen.

Seltsame Zeitzonen

Asia/Kathmandu hat einen ungewöhnlichen Offset

• Nepal liegt 5 Stunden und 45 Minuten vor UTC.
• Computer kennen diese Information über die IANA-Zeitzonendatenbank.

Zeichenketten wie PDT oder CET bedeuten nichts

• Zeitzonenkennungen können mehrdeutig sein, und viele Zeitzonen teilen sich dieselbe Kennung.

Wie werden Zeitzonen mit Sommerzeit dargestellt?

• Die Regeln für die Umstellung auf Sommerzeit sind komplex, und Computer berechnen auf ihrer Grundlage die lokale Zeit.

Africa/Casablanca und Asia/Gaza folgen dem Mond, aber Zeitzonen folgen der Sonne

• Marokko und Gaza passen ihre Sommerzeit an den Ramadan an; das wird hartkodiert.

America/Nuuk wechselt bei -1 Uhr in die Sommerzeit

• Grönland beginnt die Sommerzeit zum selben Zeitpunkt wie Europa, aber in der Ortszeit beginnt sie um -1 Uhr.

America/Santiago und Africa/Cairo wechseln um 24 Uhr

• Diese Zeitzonen wechseln um 24 Uhr in die Sommerzeit, was bedeutet, dass der nächste Tag beginnt.

Australia/Lord_Howe hat die seltsamste Sommerzeitumstellung

• Lord-Howe-Insel hat eine Sommerzeitumstellung um 30 Minuten.

Zusammenfassung von GN⁺

• Zeitzonen sind komplex, aber weil Computer sie implementieren müssen, sind sie nur innerhalb eines endlichen Rahmens seltsam.
• Australia/Lord_Howe ist mit seiner Sommerzeitumstellung um 30 Minuten die ungewöhnlichste Zeitzone.
• Dieser Artikel ist nützlich, um die Komplexität von Zeitzonen zu verstehen, und könnte für Programmierer interessant sein.
• Ein Projekt mit ähnlicher Funktionalität ist tzdb.

[GN⁺]

Hacker-News-Kommentare

• Das Interessanteste an der tz-Datenbank ist, dass sie eine Schätzung für den Zeitpunkt des Urknalls enthält und so ausgelegt ist, dass Zeitzonenwechsel vor dem Urknall nicht berechnet werden
  Auch die Commit-Message von https://github.com/eggert/tz/commit/b22d459a367f4d01b10f6f6b... ging sinngemäß darum: „Zeitstempel vor dem Urknall sind physikalisch fragwürdig, also sollten wir sie nicht erzeugen“, und kurz darauf wurden in einem separaten Commit auch Schaltsekunden vor dem Urknall verboten

  • Früher gab es eine lange Manpage zur Bedeutung historischer Datumsangaben in Linux/Unix date
    Mit Beispielen etwa aus dem 15. Jahrhundert und Geschichten darüber, dass ein König eine bestimmte Woche/einen bestimmten Monat mochte und anordnete, sie/ihn zu wiederholen, oder dass ein anderer König eine bestimmte Woche nicht mochte und sie aus dem Kalender strich. Das war eine ziemlich erhellende Lektüre, aber ich kann sie heute nicht mehr finden
  • Das wirkt wie eine ziemlich pragmatische Entscheidung. Eine gute Art, sinnlose Debatten unter Beitragenden nach Art der Engel-auf-einer-Nadelspitze-Diskussion von vornherein zu verhindern
    Anders gesagt läuft es auf die Schlussfolgerung hinaus: „Zeitpunkte vor dem Urknall liegen außerhalb des Geltungsbereichs dieser Library; wenn ein Algorithmus also nur vor dem Urknall falsche Werte liefert, ist dieser Algorithmus akzeptabel und muss nicht verbessert/ersetzt werden.“
  • Das ist wirklich ein großartiges Detail, aber unabhängig davon bin ich etwas skeptisch gegenüber dem Versuch von tzdb, sogar Zeiten vor der Unix-Epoch abzudecken
    Der Nutzen im Verhältnis zu möglichen Bugs erscheint mir dort nicht besonders groß, und der Großteil der unordentlichen Komplexität von tzdb steckt in zic. Manchmal habe ich das Gefühl, es wäre besser gewesen, wenn zic kein Artefakt wäre, auf das sich andere verlassen können
  • Ein interessantes Easter Egg der TZ-Datenbank. Ich höre zum ersten Mal davon, frage mich aber, wie oft man wirklich so alte Zeitzonendaten berechnen muss
    Hoffentlich verschwinden Zeitzonen selbst, bevor die Zeitzonentheorie veraltet

• Die seltsamste Zeitzone ist meiner Meinung nach Africa/Addis_Ababa. Gerade die Menschen vor Ort in Äthiopien verwenden dieses System nicht
  Lokal wird die Uhrzeit um 6 Stunden verschoben: Der AM-Zyklus beginnt im Morgengrauen, also um 6 Uhr morgens, und der PM-Zyklus beginnt bei Sonnenuntergang, also um 18 Uhr
  https://en.wikipedia.org/wiki/Time_in_Ethiopia

  • Das ist in ganz Ostafrika, einschließlich Kenia, üblich. Die Nacht endet um 6 Uhr morgens, und 7 Uhr morgens ist als saa moja die erste Stunde des Tages
    Entsprechend endet der Tag um 18 Uhr, thenashara. Intuitiv ergibt das viel mehr Sinn als die Uhr im englischsprachigen Raum, und da es in der Sprache verankert ist, kommt es nur selten zu Zeitverwechslungen
  • Die äthiopische Zeitrechnung ist insgesamt ungewöhnlich
    https://en.wikipedia.org/wiki/Ethiopian_calendar
    Der äthiopische Kalender besteht aus 12 Monaten mit je 30 Tagen sowie 5 oder 6 Schalttagen, die den 13. Monat bilden
  • Das ist der Art, wie die Römer Zeit verstanden, sehr ähnlich. Ich frage mich, ob das ein altes Überbleibsel aus der Zeit ist, als Nordafrika in mehrere Provinzen aufgeteilt war
    https://en.wikipedia.org/wiki/Roman_timekeeping
  • Für ein Land nahe dem Äquator ist das als Definition des Tageszyklus nicht wirklich irrational
  • Japan verwendet in Zusammenhängen wie Einrichtungen, die nach Mitternacht schließen, ein ähnliches System: https://en.wikipedia.org/wiki/Date_and_time_notation_in_Japa...
    Im englischsprachigen Raum begann früher das neue Jahr ebenfalls am 25. März: https://en.wikipedia.org/wiki/Calendar_(New_Style)_Act_1750#...
    Beides ist technisch gesehen nichts, womit tzdb umgehen kann. tzdb behandelt bürgerliche Zeit, nicht Kalender oder andere Rechensysteme

• Die Seltsamkeit von Asia/Jerusalem liegt daran, dass die Sommerzeit stark mit Fragen der Trennung von Religion und Staat verknüpft ist. Religiöse Menschen möchten, dass der Arbeitstag passend zu Feiertagen liegt, die bei Sonnenuntergang beginnen
  Deshalb war die Sommerzeit über Jahrzehnte bis Mitte der 2000er jedes Jahr das Ergebnis von Verhandlungen zwischen religiösen und säkularen Parteien, und die Umstellungstermine wurden oft erst kurz vor der Umstellung festgelegt, was häufig Probleme verursachte
  Offenbar gibt es noch immer eine Ausnahme, die verhindert, dass die Sommerzeit an Rosh HaShanah endet, weshalb die zukünftigen Regeln wohl kompliziert aussehen

  • Da die Vorteile der Sommerzeit begrenzt sind, insbesondere in einem relativ südlich gelegenen Land, frage ich mich, warum man sie nicht einfach ganz abgeschafft hat
    Wenn die EU es am Ende schafft, sie abzuschaffen, könnte man vielleicht nachziehen
  • Es liegt am Pessachfest. Das große Festessen namens Seder dauert bis nach Mitternacht und ist auch für Kinder ein sehr wichtiges Ereignis
    Deshalb will man nicht, dass die Sommerzeit eine ohnehin spät endende Veranstaltung noch später macht. Außerdem wollte man, dass am Fastentag Jom Kippur das Fasten eine Stunde früher endet. Der Versuch, sich nach diesen Daten zu richten, machte die Sommerzeitperiode zu kurz, sodass Verhandlungen nötig wurden
  • Es gibt keine Ausnahmen mehr. IDT wurde 2013 bis zum letzten Sonntag im Oktober verlängert

• Die Aussage, „Programmiersprachen können keine 61 Sekunden lange Minute darstellen“, stimmt so nicht. Jemand hat bereits erwähnt, dass Raku Schaltsekunden unterstützt, und das könnte teilweise meine Schuld sein
  Denn DateTime.pm, die populärste Datums-/Zeitbibliothek in Perl 5, unterstützt Schaltsekunden, und ich habe diese Unterstützung beim Erstellen von DateTime.pm implementiert
  Rückblickend war das ziemlich sicher ein Fehler. Für Schaltsekunden interessieren sich kaum Leute, und sie erzeugen nur merkwürdige Verwirrung wie: „Warum ist 60 Sekunden addieren manchmal nicht dasselbe wie 1 Minute addieren?“
  Besonders weil versucht wurde zu validieren, ob second => 60 gültig ist, wurde der Code deutlich komplexer. Der Konstruktor nimmt Zeitkomponenten und eine beliebige Zeitzone entgegen; um die Schaltsekundentabelle zu prüfen, muss man also nach UTC konvertieren, aber genau diese Konvertierung ist aus historischen Gründen selbst mit Werten verknüpft, die Schaltsekunden enthalten
  Für einen winzigen Nutzen wurde daraus ein riesiges Durcheinander, und da Rakus Standardbibliothek für Datum/Zeit offenbar stark von Perl 5s DateTime.pm übernommen hat, hat sie meiner Ansicht nach einige derselben schlechten Designentscheidungen geerbt

  • Es ist gut, dass es so implementiert wurde und man später auf elegantere Lösungen zurückblicken konnte
    Ich frage mich, wie der ursprüngliche Denkprozess war. War man zu sehr in das Problem vertieft? Wenn man einem Problem zu nah ist und sich zu lange darauf konzentriert, passiert so etwas leicht, weil die Freude daran, etwas zu reparieren, bevor es kaputtgeht, überwiegt
  • In Raku gibt es die Klasse Instant
    Sie ist sinngemäß definiert als: „Ein Instant ist ein bestimmter Zeitpunkt, gemessen in atomaren Sekunden und deren Bruchteilen, und ist an keine Epoche gebunden bzw. sich keiner bewusst“

• Anfang dieses Jahres musste ich eine Funktion schreiben, die bei einer gegebenen US-Adresse die aktuelle lokale Uhrzeit ermittelt. Der naive Ansatz wäre, Bundesstaaten statisch auf Zeitzonen abzubilden, aber es gibt etliche Ausnahmen, die das verhindern
  In der betreffenden Anwendung waren Kosten und Geschwindigkeit wichtig, also kaufte ich für ein paar Dollar eine CSV, die alle US-ZIP Codes auf UTC-Offset, Einhaltung der Sommerzeit und Ähnliches abbildet
  Da pytz IANA-Zeitzonennamen erwartet, musste ich Offset- und Sommerzeitinformationen am Ende manuell auf bestimmte Zeitzonen mappen, und wegen US-Außengebieten und Militärbasen waren auch seltsame Semantiken wie bei Etc-Zeitzonen nötig
  [1] https://en.wikipedia.org/wiki/Tz_database#Area

  • Die Ebene der Bundesstaaten hat eine völlig falsche Auflösung. US-Zeitzonen folgen County-Grenzen und Grenzen von Reservaten indigener Völker
    ZIP Codes können vermutlich ausreichen, aber man muss vorsichtig sein. Wenn es nicht zu viele Adressen sind, ist ein robusterer Ansatz, per Reverse Geocoding zu arbeiten und dann mit einer Bibliothek aus den Zeitzonen-Grenzpolygonen den IANA-Identifier zu ermitteln
    https://github.com/RomanIakovlev/timeshape wird von einem ehemaligen Kollegen gepflegt; wir konnten einen Teil der internen Arbeit als Open Source veröffentlichen
  • 1985, als ich ein junger Ingenieur frisch von der Uni war, bekam ich die Aufgabe, Telemetriedaten zusammenzuführen, die an mehreren Radarstandorten in den USA auf Magnetband aufgezeichnet worden waren
    Ein oder zwei Systeme stempelten die Daten mit lokaler Zeit, die übrigen verwendeten UTC. Um einen Algorithmus für den Umgang mit der Sommerzeit zu erstellen, kaufte ich einen alten Farmers' Almanac, las die Regeln und verzweifelte
    Im Kalender standen nominelle Regeln für die Umstellung, aber auch eine Fußnote, dass sie wegen Eingriffen des Kongresses von Jahr zu Jahr angepasst worden waren und das wohl auch weiterhin würden. Ich sagte meinem Chef: „Wenn ich einen Algorithmus schreiben könnte, der künftige Abstimmungen des Kongresses vorhersagt, wäre ich Milliardär und hätte diesen Ingenieursjob gekündigt“
    Am Ende habe ich wohl die jüngsten bekannten Umstellungen und die künftigen nominellen Regeln codiert. Das war, bevor alle vernetzt waren, und der Code lief auf Standalone-Rechnern wie VAX-Systemen, also gab es kaum andere Möglichkeiten
    Auch das Zusammenführen von drei Tracking-Datenquellen, jeweils mit eigenem Gültigkeits- und Messqualitäts-Degradationsstatus, war ein Albtraum, aber immer noch einfacher, als künftiges Handeln des Kongresses vorherzusagen
  • Ein guter Ansatz ist, ZIP Codes auf benannte Zeitzonen wie US/Eastern abzubilden. Wenn man danach einen UTC-Offset braucht, wendet man mit pytz die Zeitzone auf das jeweilige Datum an und erhält den Offset
    Benannte Zeitzonen sind insofern besonders, als sie stabil sind. UTC-Offset-Zeitzonen wie -05:00 oder Abkürzungen wie EST sind wegen der Sommerzeit an einem bestimmten Ort über die Zeit hinweg nicht stabil
    Wenn man jemanden nach seiner Zeitzone fragt und als Optionen Offsets oder Abkürzungen anbietet, stiftet das bei allen Verwirrung
  • Anfang dieses Jahres habe ich etwas Ähnliches gemacht: Ich nutzte einen Geolocation-Dienst, um Adressen in Breiten-/Längengrad umzuwandeln, und ermittelte daraus wiederum die Zeitzone. Für Bundesstaaten mit nur einer Zeitzone gab es einen Shortcut
    Für die Umwandlung Breiten-/Längengrad → Zeitzone habe ich diese Python-Bibliothek verwendet: https://github.com/jannikmi/timezonefinder
    Auch die Datenquelle sah nach einer recht hochwertigen Quelle aus: https://github.com/evansiroky/timezone-boundary-builder/rele...
  • Bei Etc-Identifiern muss man wirklich vorsichtig sein. Besonders dann, wenn man alle Identifier unverändert den Nutzern anzeigen wollte
    In der betreffenden Datei steht der Kommentar: „POSIX setzt Werte westlich von Greenwich positiv, aber viele Menschen erwarten Werte östlich von Greenwich als positiv. Zum Beispiel verwendet TZ='Etc/GMT+4' die Abkürzung -04 und bedeutet 4 Stunden hinter UT, also westlich von Greenwich, aber viele Menschen erwarten 4 Stunden vor UT, also östlich davon“

• Auch die Zeitzone Palästinas ist ziemlich merkwürdig
  https://en.wikipedia.org/wiki/Time_in_the_State_of_Palestine
  Es gibt zwar Sommerzeit, aber die Daten sind nicht festgelegt; die Regierung gibt jedes Jahr Beginn und Ende bekannt. Manchmal geschieht das weniger als eine Woche vorher, was zwangsläufig allerlei interessante Probleme verursacht.

  • Dadurch kann es passieren, dass zwei Menschen, die am selben physischen Ort leben, je nach ethnischer bzw. geopolitischer Identität unterschiedliche aktuelle Zeiten befolgen
    Die Start- und Enddaten der Sommerzeit in Israel und Palästina sind nicht zwingend identisch
  • Ich weiß nicht, ob es heute noch so ist, aber in Brasilien war das früher auch so. Deswegen hätte ich einmal fast ein Flugzeug verpasst
  • Das steht tatsächlich im Artikel und hängt mit dem Ramadan zusammen
  • Auch ohne tief in die Politik einzusteigen, verstehe ich nicht recht, warum man der Sommerzeit so hohe Priorität einräumt. Es scheint deutlich größere Sorgen zu geben

• Eine Sommerzeit mit 30 Minuten statt 1 Stunde Unterschied als „merkwürdigste Zeitzone“ zu bezeichnen, setzt die Messlatte meiner Meinung nach zu niedrig
  Fast alles andere ist merkwürdiger. Antarctica/Troll klingt definitiv seltsamer, und die Zeitzonen von Marokko und Gaza haben zumindest eine andere Art von Regeln, weil sie sich mit den bestehenden Systemen kaum ausdrücken lassen. Auch die Zeitzonen auf Apples Sperrliste, bei denen die Umstellung am Tag vor einem bestimmten Datum erfolgt, sind seltsam genug, um Dinge kaputtzumachen
  Bei Schaltsekunden stimme ich zu. Das ist weniger nützliches Wissen für Programmierer als vielmehr Trivia. Computer verschmieren Schaltsekunden, und man weiß nicht einmal, wann sie passiert sind. Man kann sie völlig vergessen
  Allerdings haben Länder einmal von einer Praxis, Schaltsekunden zu ignorieren, zu einer Praxis gewechselt, sie zu berücksichtigen; die Umstellung Australiens von GMT+x auf UTC+x vor einigen Jahrzehnten war also ein Übergang vom Ignorieren zum Einbeziehen von Schaltsekunden. Dass diese Tatsache nahezu allgemein ignoriert wird, ist vielleicht sogar besser so

  • Ich stimme im Großen und Ganzen zu, dass Schaltsekunden Trivia sind
    Aber es ist immer ein bisschen lustig, wenn eine große Organisation sagt: „Unsere Server haben dank GPS-Synchronisierung und selbst entwickelten PCIe-Rubidium-Atomuhrkarten eine Zeitgenauigkeit unter einer Millisekunde“, und gleichzeitig: „Schaltsekunden werden über einen Tag verschmiert, also ist es praktisch egal, wenn die Serverzeit um ±0,5 Sekunden danebenliegt“
    [1] https://engineering.fb.com/2021/08/11/open-source/time-appli...
    [2] https://engineering.fb.com/2020/03/18/production-engineering...
  • Das Datum des Ramadan ist kein allgemein bekannter Wert. Es basiert nämlich darauf, ob der Mond in einer bestimmten Region der Erde tatsächlich sichtbar ist
    Wenn der Himmel zum Beispiel sehr bewölkt ist, kann man den Mond nicht sehen, egal wo er steht. Das verursacht Probleme, wenn man einen Kalender für den Staatsbetrieb implementiert
    Viele Länder, die den islamischen Kalender offiziell verwenden, nutzen im Voraus berechnete Näherungsdaten auf Basis der erwarteten Sichtbarkeit an einem bestimmten Ort. Der islamische Kalender ist daher eigentlich nicht einer, sondern eher zwei: ein beobachtungsbasierter islamischer Kalender und ein vorhergesagter Kalender; beide hängen vom Ort der tatsächlichen oder vorhergesagten Beobachtung ab
    Ich weiß nicht, wie Marokko oder Gaza das handhaben
  • Antarctica/Troll ist nicht so ungewöhnlich. Praktisch nutzt man dort während des kurzen Sommers die Zeit von Kapstadt und im Rest des Jahres die norwegische Zeit
    Nur verwendet die norwegische Zeit eben zufällig Sommerzeit
  • Schaltsekunden sind größtenteils Trivia, werden aber entscheidend wichtig in Anwendungen, in denen mehrere Parteien sich exakt über die zeitliche Reihenfolge einigen müssen. Ein typisches Beispiel sind Finanztransaktionen
    Viele Märkte waren während Schaltsekunden geschlossen, und viele Banken setzen bei lokalen Zeitumstellungen weiterhin alle Transaktionen aus, um das Fehlerrisiko zu verringern
    Selbst in Anwendungen, in denen man sich nicht besonders darum kümmert, gab es überraschend viele Bugs im Zusammenhang mit Schaltsekunden, und es gibt gute Gründe dafür, dass die CGPM die Abschaffung von Schaltsekunden beschlossen hat
    https://en.wikipedia.org/wiki/Leap_second#Other_reported_sof...
  • Ich bin wegen Troll hergekommen. Soweit ich weiß, ist es der einzige Ort mit Winter-Sommerzeit, und der Name bringt noch Zusatzpunkte

• Ein großartiger Artikel über die Akrobatik von Zeitzonen-Software. Wirklich ziemlich flexibel
  Wenn alles automatisierte, endliche Offsets sind, gibt es keinen Grund, warum Sommerzeit-Regeln unbedingt auf 60-Minuten-Anpassungen zugeschnitten sein müssen.
  Könnte sich nicht irgendein Land dafür entscheiden, das ganze Jahr über kontinuierlich veränderliche Offsets zu verwenden? Die Offset-Lookup-Tabelle würde deutlich länger, aber so ließe sich die Sommerzeit vielleicht „lösen“. Da ständig nur ein wenig nachjustiert würde, würde man es wie bei Schaltsekunden kaum bemerken.
  Menschen, die auf analoge Uhren angewiesen sind, würden sie vielleicht nicht mehr jedes Mal in dieselbe Richtung stellen.

  • Seit die Uhrensynchronisierung bei elektronischen Geräten üblich geworden ist, schlage ich jedem, der zuhört, vor, sechs Monate lang an jedem ersten Sonntag im Monat um 10 Minuten vorzustellen und in den restlichen sechs Monaten an jedem ersten Sonntag im Monat um 10 Minuten zurückzustellen.
    Eine Änderung um 10 Minuten einmal im Monat ist viel leichter zu verkraften und fällt kaum auf; selbst wenn man sie verpasst, ist es nicht so schlimm wie eine Abweichung um eine Stunde.
  • Wenn man diesen Weg geht, ist die logische Konsequenz, das Konzept von Zeitzonen ganz abzuschaffen und zur lokalen Sonnenzeit zurückzukehren.
  • Ihr ignoriert die einfachste Methode, die Sommerzeit zu „lösen“.
    Man schafft die Sommerzeit ab. Persönlich bevorzuge ich dauerhafte Standardzeit gegenüber dauerhafter Sommerzeit, aber ich könnte damit leben, solange wir nur aufhören, zweimal im Jahr die Uhren umzustellen.
  • Indien liegt bei UTC+5:30 und hat keine Sommerzeit, was bei der Interaktion mit der Welt interessant ist.
    China ist natürlich bekannt dafür, trotz seiner enormen Breite nur eine einzige Zeitzone zu haben, was sowohl intern als auch extern interessante Situationen schafft.
  • Theoretisch lässt sich das mit tzdb ausdrücken. Natürlich würde es Probleme verursachen.
    Eine wirklich wichtige Annahme, die im TZif-Datenformat nicht ausdrücklich sichtbar ist, lautet: Beim Übergang von lokaler Zeit zu UTC-Zeit gibt es höchstens zwei Möglichkeiten.
    Viel Software stützt sich auf diese Annahme; zum Beispiel gibt es in java.time.LocalDateTime withLaterOffsetAtOverlap(): https://docs.oracle.com/javase/8/docs/api/?java/time/LocalDa...
    Das setzt implizit voraus, dass es, wenn unklar ist, was 2:30 Uhr bedeutet, nur zwei mögliche Lösungen gibt: vor und nach der Sommerzeitumstellung. Wenn eine Zeitzone um 2:00 Uhr einmal zurückstellt und um 2:15 Uhr noch einmal, sodass drei oder mehr Lösungen entstehen, können viele Dinge das nicht darstellen.

• Was mir an der tz-Datenbank gefällt: Technisch gesehen ist sie ein Diff des Diffs.
  Sie speichert, wie sich die Differenz zwischen jeder Zeitzone und UTC historisch verändert hat, man kann sie also als diff^2 betrachten. Aber die tz-Datenbank erhält außerdem Updates, also sind diese Commits ein Diff des Diffs des Diffs, also diff^3.
  Man kann noch weiter gehen. Es gibt ein Änderungsprotokoll, und dieses Änderungsprotokoll liegt in git; damit ist ein Commit am tz-Änderungsprotokoll eine Änderung an der Änderungsliste der Änderungsliste der Änderungsliste relativ zu UTC, also diff^4.

  • Du hast ausgelassen, dass UTC, und im weiteren Sinne die Zeitmessung selbst, ebenfalls ein Diff ist.
  • Ein Diff eines Diffs sind einfach zwei Diffs. Es ist kein Produkt von Diffs.

• Ich denke, der entscheidende Frame ist: Fast jedes Datum/jede Uhrzeit ist in Wirklichkeit eine überwachte Menge von Matching-Regeln.
  Man kann schätzen, wie viele Sekunden es dauern wird, bis ein Match ausgelöst wird, aber völlig sicher kann man erst sein, wenn es tatsächlich passiert; und in manchen Fällen passiert es vielleicht gar nicht exakt.
  Die andere Hälfte besteht dann darin, die Delta-Schätzung „es passiert vermutlich in X Sekunden ab jetzt“ wieder zurückzuübersetzen in „zu diesem Zeitpunkt wird die Uhr in deiner Zeitzone vermutlich Y anzeigen“.
  Man darf nicht vergessen, laufend nachzuverfolgen, welche Zeitzone das Ereignis steuert und in welcher Zeitzone es angezeigt wird.
  [1] UTC-Schätzungen können um Schaltsekunden nach vorn oder hinten danebenliegen. TAI ist sicherer, aber auch das könnte sich ändern, falls jemand etwas Interessantes und Neues entdeckt, das das Verhalten von Cäsiumatomen verändert.
  [0] Zum Beispiel könnte ein Staat verschwinden und damit auch seine Zeitzone. Oder eine Uhr könnte von 1:00 auf 2:00 springen, sodass wegen der ausgelassenen Stunde der Zeitraum von 1:30 bis 2:00 nie exakt eintritt.