Anno 1601

Nachdem ich mit der Anno-Spiele-Serie nie direkt in Berührung gekommen bin und nur davon gelesen habe, handelt dieser Artikel nicht von der Besiedelung unentdeckter Welten.

Es geht um die Zeitrechnung auf unseren Computern.


Zeitpunkte werden in der Programmierung intern am einfachsten durch eine Ganzzahl dargestellt und nicht durch die für Menschen lesbaren Jahr-Monat-Tag Gruppen.

Das hat rechnerisch große Vorteile, weil man ganz einfach addieren und subtrahieren kann und vorerst diverse Regeln des Kalenders nicht beachten muss (wie Monatslängen und Schaltjahre).
Offen bleibt die Frage: Wo fangen wir mit Null an?

Kalender sind dann zusätzlich noch so eine Sache. Zwar hat sich in der Wirtschaft die christliche Zeitrechnung etabliert, aber letztendlich haben viele Staaten ihren eigenen (oft stark religiös geprägten) Kalender und der Anspruch an Software ist es, diesen jeweils korrekt darzustellen.

Während Unix / POSIX basierte Systeme ihre Zeitrechnung mit dem 1. Januar 1970 starten, begann das klassische MAC-OS am 1. Januar 1904.

Microsoft wählte den 1. Januar 1601 … und das gefällt mir offen gesagt am besten.

Die Zeitrechnung der Betriebssysteme dient in erster Linie den Systemen selbst und ist nicht primär für Anwendungsszenarien ausgelegt. Wir reden hier z.B. von Zeitstempeln für das Anlegen von Dateien. Nachdem es vor 1970 kein Unix gab, machte es auch wenig Sinn Zeitpunkte vor 1970 “erreichbar” zu machen.

Fakt ist aber, dass Anwendungsprogramme dann nicht auf die Zeitrechnung des Systems zurückgreifen können, denn eine Tabellenkalkulation muss schon auch ältere Datumsangaben zulassen, wenn man z.B. die Bauteillieferung der Titanic in einem Excel Sheet erfassen möchte.

Der Startpunkt im Jahr 1601 lässt uns recht weit in die Vergangenheit zurückreisen, hat den Vorteil mit einem Montag zu starten und ist vor allem der Beginn eines Kalenders, der bis heute keine unregelmäßigen Sprünge beinhalten musste. Wir sprechen vom gregorianischer Kalender.

Dieser Kalender wurde unter Papst Gregor im Jahr 1582 eingeführt und musste 10 Tage einfach auslassen, um wieder zu einer Zählung zu gelangen, die kirchenrechtlich mehr als ein Jahrtausend davor beschlossen wurde. Die Schaltjahr Regelung wurde so angepasst, dass die Abweichung der Tagesdauer gegenüber der Zeitrechnung über Jahrtausende hinweg stabil bleibt.

Im älteren julianischen Kalender war das nicht so, weshalb die Datumsangaben für den Jahreswechsel und das Äquinoktium sich im Laufe der Zeit änderten.

Das heißt also, dass wir ab 1583 linear in Ganzzahlen rechnen können und das anzeigbare Datum durch ein paar Divisionen ganz leicht ausrechnen können.

Und 1601 hat den Vorteil, dass hier ein Jahrhundert startete und der Januar auf einen Montag fiel.

Aus diesem Grund nutzt auch das GATE Projekt den 1.1.1601 als Null-Punkt für interne Zeitrechnungen.

Microsoft entschied sich in 100-Nanosekunden Intervallen zu zählen. GATE hingegen arbeitet mit Mikrosekunden um die Umrechnung in Sekunden ebenfalls “schöner” zu gestalten. Gezählt wird in einem 64 bit signed integer, womit wir vermutlich bis zum Ende der IT wie wir sie kennen locker alles abbilden können.

Unix hatte sich mit der Zählung von Sekunden seit 1970 mit anfangs 32 bit Integer Werten keinen Gefallen getan, denn im Jahr 2038 laufen die 32 Bit Integer über und springen auf den 13. Dezember 1901 zurück. Es ist zu hoffen, dass in 20 Jahren also kein Unix mehr eingesetzt wird, welches eine 32-bit Zeitrechnung nutzt … ansonsten geht erneut seit dem Jahr 2000 die Welt unter.

Zum Glück hatte die Sprache C schon früh einen Patch für dieses anfängliche Designproblem in Unix gefunden, nämlich typedef.
Und so wurde der Datentyp time_t von ursprünglich 32 bit still und heimlich auf 64 bit erweitert.
Somit sollte heute kein neues Unix mehr entstehen, das mit weniger als 64 bits rechnet.

… aber genaueres werden wir in 20 Jahren dann wissen.

📧 📋 🐘 | 🔔
 

Meine Dokus über:
 
Weitere externe Links zu:
Alle extern verlinkten Webseiten stehen nicht in Zusammenhang mit opengate.at.
Für deren Inhalt wird keine Haftung übernommen.



Wenn sich eine triviale Erkenntnis mit Dummheit in der Interpretation paart, dann gibt es in der Regel Kollateralschäden in der Anwendung.
frei zitiert nach A. Van der Bellen
... also dann paaren wir mal eine komplexe Erkenntnis mit Klugheit in der Interpretation!