-
Option 1: separate Zahlen für Jahr, Monat, Tag, Stunde, Minute, Sekunde
- Verwendung vor allem an Stellen, wo der Nutzer es sehen kann (Zeitanzeigen, Zeitstempel in Dateinamen etc.)
- Vorteil: sofort menschenlesbar
- Nachteil: muss für Eindeutigkeit immer mit Zeitzoneninformation verknüpft sein; Gültigkeit von zukünftigen Zeitangaben evtl. durch nicht vorhergesehene Zeitzonenänderungen beeinträchtigt
- Nachteil: textuelle Darstellung je nach Kulturkreis uneindeutig (z.B. "4/7/2021" kann entweder für den 4. Juli oder den 7. April stehen)
-
Option 2: eine einzelne Zahl, die die vergangene Zeit in einer bestimmten Einheit (z.B. Sekunden oder Tage) seit einem Startzeitpunkt (der Epoche) angibt
- z.B. Unix: Sekunden seit 1. Januar 1970 00:00:00 Uhr UTC (bzw. 01:00:00 Uhr deutscher Zeit)
- z.B. julianisches Datum: Tage seit 1. Januar 4713 v.u.Z.
- z.B. Excel, LibreOffice Calc, etc.: Tage seit 1. Januar 1900, mit Nachkommastellen für Zeitpunkte innerhalb eines Tages
-
Probleme durch Überlauf in Datumsfeldern
- Y2K-Problem: Überlauf in der Jahreszahl, die damals zweistellig angegeben war (z.B. "76" für 1976)
- Y2038-Problem: Überlauf in einem 32-Bit-Unix-Zeitstempel (am Dienstag, dem 19. Januar 2038 um 04:14:07 Uhr deutscher Zeit)
- GPS-Wochen-Rollover: Überlauf in der Wochenzahl des Zeitstempel-Formats von GPS; erstmals 1999, zuletzt 2019, nächstes Mal 2038
-
Probleme durch astronomische/politische Fakten
- Berechnungen wie "10 Tage dazuaddieren" mühselig aufgrund Kalenderregeln (Monatswechsel, Schalttage etc.)
- Beispiel: in einer Terminserie wie "täglich um 15 Uhr" hat wegen Sommerzeitwechsel nicht jeder Termin genau 24 Stunden Abstand zueinander
- Beispiel: Sommerzeitumstellung bei der Eisenbahn (diesen Abschnitt können wir im Prinzip direkt vorlesen)
- Schaltsekunden lassen UTC springen und erzeugen unerwartete Zeitzustände wie "23:59:60"
- Zeitzonendefinitionen folgen politischen Entscheidungen
- z.B. Deutschland besteht in tzdata aus zwei Zeitzonen
- z.B. 2015 Chaos in der Türkei durch eine Änderung der Sommerzeitregel mit zu wenig Vorlauf
-
Probleme durch technische Einflüsse
- Hardware-Uhren sind nicht hinreichend genau und driften mit der Zeit: in verteilten Systemen mögliche Verwirrung über die Reihenfolge von Aktionen
- Zeitsynchronisation mittels NTP (Network Time Protocol): im Moment der Richtigstellung der Uhr mögliche Verwirrung durch einen kleinen Sprung rückwärts in der Zeit
- Suspend/Standby: im Moment des Wiederanschaltens mögliche Verwirrung durch einen drastischen Sprung vorwärts in der Zeit
- monotonische Uhren: zählen die Zeit, die der Computer seit Systemstart gelaufen sind (z.B. mittels TSC; damit zuverlässige Messung von Laufzeitspannen etc.
-
positiver Ausblick: Es könnte noch viel schlimmer sein!
- gregorianischer Kalender hat sich weltweit für den Geschäftsverkehr durchgesetzt
- Beispiel für einen alternativen Kalender: Japanische Zeitrechnung
-
kryptografisch abgesicherte Zeitstempel: RFC Podcast #15 Crypto for the Masses
