Interne Formate für Datum & Zeit @ PS-Trainer

Interne Darstellung von Datum und Zeit

Viele IT-Systeme (Betriebssysteme, Programme) müssen mit Datum und Zeit umgehen. Dafür wurden daher eigene Daten-Typen, Eigenschaften und Methoden entwickelt.
Die Ziele (rechts) werden von den realen System auf unterschiedliche Weise erreicht.
Für die heute verwendeten Typen sind die historische Entwicklung und kulturspezische Unterschiede noch deutlich merkbar.

Die Ziele für interne Datum-Zeit-Typen:
▲ Datum und Zeit müssen eindeutig gespeichert und wieder-erkannt werden.
▲ Man muss mit Datum und Zeit rasch und einfach rechnen können, insbesondere mit Differenzen.
▲ Für Transport, Eingabe und Darstellung muss man interne Formate muss man in andere standardisierte Formate umgewandeln.

Technische Vorgaben zur Erstellung von Datum & Zeit - Systemen:

● Die Anzahl einzelner Daten wird durch die Anwendung bestimmt. Für den Transport gut geeignet sind ↓ Strukturen von 3 oder 6 Zahlen (z.B. Jahr, Monat, Tag, ...). Als interne Speicherform, vor allem jedoch zum Rechnen werden ausschließlich Daten verwendet, die in einer einzigen Zahl sowohl Datum ald auch Zeit codiert haben. Alle weiteren Überlegungen dieses Kapitels treffen nur auf solche Daten zu.

● Die Wortbreite in Bit ist die wichtigste Vorgabe. Heutige PC verwenden 32bit oder 64bit Worte, die nächste PC-Generation kann zusätzlich 128bit Worte verwenden.
Ein spezielles Beispiel ist der ↓ UNIX-Timestamp, welcher derzeit mit 31 bzw. 32 Bit nur bis zum Jahr 2038 reicht. Das ist sehr knapp. Bis dahin wird es allerdings keine 32bit-PC mehr geben, sondern Wortbreiten von mindestens 64 oder 128 Bit. Das wiederum reicht für beliebige Zeiträume (d.h. mehr als das Alter des Universums).
Der Timestamp ist sozusagen eine bewußte aber sehr realistische Spekulation auf den technischen Fortschritt.

● Zahlenformat: Datum & Zeit können wahlweise als Ganze Zahlen (Integer) oder Gleitkomma-Zahlen (Real, Float) gespeichert werden. Ein wichtiger Unterschied ist die wesentlich größere Geschwindigkeit bei der Verarbeitung von Ganzen Zahlen.
Derzeit verwendete Gleitkomma-Zahlen benötigen darüber hinaus für Datum & Zeit-Darstellung ca. 50% mehr Speicherplatz.

● Die Genauigkeit (Auflösung) bestimmt, welche kleinste Zeit-Differenz über die gesamte Zeit-Skala gerade noch unterscheidbar ist. Sekunden sind Mindest-Anforderung, meist werden ms (1E-3s) oder μs (1E-6s) verlangt.
• Die Genauigkeit von Ganzen Zahlen beträgt absolut +/- 1 über den gesamten Bereich.
• Die Genauigkeit von Gleitkomma-Zahlen ist relativ, d.h. abhängig von der Größe der dargestellten Zahl. Wenn eine bestimmte absolute Genauigkeit (z.B. +/- 1 Sekunde) gefordert wird, dann wird dadurch der nutzbare Werte-Bereich stark eingeschränkt.

Ergebnis: Die Länge des darstellbaren Datum & Zeit - Bereichs
Aus den technischen Vorgaben (oben) ergibt sich zwangsläufig die Länge dieses Zeitraums - Er sollte natürlich möglichst groß sein, nach heutigen Vorstellungen mindestens 100 Jahre, besser jedoch einige 1000 Jahre.
Der Idealfall wäre ein Bereich von einigen 10 Milliarden Jahren - damit wären alle möglichen vergangenen und zukünftigen Zeiten unseres Kosmos abgedeckt.

Die Bereiche wichtiger verwendeter Systeme sind 136 Jahre (theoretisch) bzw. 68 Jahre (real) für den heutigen UNIX Timestamp in Sekunden, 24 Mio Jahre (theoretisch) bzw. 10000 Jahre (real) für das Windows Y1900-System.

● Reale Software verbessert diese Daten in vielen Fällen:
→ Javascript (ihr Browser) kann mit einem modifizierten Timestamp ca. 550 000 Jahre bei einer Kurzzeit-Auflösung von 1 ms darstellen.
Ein zukünftiger 64bit-UNIX-Timestamp kann >500 Mia Jahre (Sekunden-Genauigkeit) oder >500 Mio Jahre (Millisekunden) darstellen.

Allen Datum + Zeit-Systemen (auch allen Kalendern) gemeinsam ist die willkürliche Festlegung des Nullpunkts. Früher legte man diesen Punkt gerne an religiös, heroisch oder sonstwie politisch wichtige Daten (Hebräische Weltschöpfung, Christi Geburt, Mohammeds Hedschra, Französische Revolution, ..)
Heutige Systeme erlauben solche Motive nur im engen Rahmen der technischen und kommerziellen Optimierung.

● Der Nullpunkt markiert das 'frühe' Ende der jeweiligen Zeitskala und kann selten unterschritten werden (negative Zeiten können meist nicht verwendet werden).
Die Wahl des Nullpunkts ist ein Kompromiss, um mit dem gegebenen Zeit-Bereich möglichst viele praktisch wichtige Daten darzustellen.
Der UNIX Timestamp verwendet den Nullpunkt 1970-01-01, das Y1900-System 1900-01-01, einige Skalen andere Nullpunkte.

Sekunde oder Millisekunde (ms) als ganzzahlige Einheit:

Datum und Zeit werden in Sekunden oder Millisekunden (ms) ab dem jeweiligen Nullpunkt gezählt.
Die Tabelle zeigt den maximal darstellbaren Zeitraum, abhängig von Wortbreite und Genauigkeit:

Wortbreite	Bereich
8 Bit	256 sec	4.27 min
16 Bit	65.536 sec	18.2 h
32 Bit	4.295*10⁹ sec	136.1 Jahre
64 Bit	1.845*10¹⁹ sec	584 Mia Jahre
64 Bit	1.845*10¹⁹ ms	584 Mio Jahre

Kleine Zeit-Einheiten wie sec oder ms werden als Ganze Zahlen ohne Vorzeichen (Unsigned Integer) gespeichert und verwendet.
● Das bedeutet in der Informatik eine wesentlich höhere Geschwindigkeit der Verarbeitung.

● Die Tageszeiten 0:00, 12:00 und 24:00 entsprechen den Zahlenwerten 0, 12*60*60=43200 und 24*60*60=86400 in Sekunden.

Aus der Tabelle geht hervor, dass Wortlängen <32 Bit sinnlos sind. Andererseits reicht die Wortlänge 64 Bit schon weit über das Alter des Universums hinaus.
64 Bit Millisekunden reichen immerhin noch für eine halbe Milliarde Jahre mit einer Genauigkeit von 1/1000 Sekunde.

Alle modernen Betriebssysteme und Programmiersprachen verwenden ganzzahlige Sekunden oder Millisekunden (ms) für bequem zugängliche Daten. Intern oder mit speziellen Modulen werden Mikrosekunden (μs) oder kleinere Einheiten verwendet.

Beispiele:
Unix- (und Linux)-Betriebssysteme (↓ Timestamp), Unix- und Linux-Dateisysteme, die Programmiersprachen JavaScript, Java, Perl, PHP, die meisten SQL-Dialekte, usw.

Tag als Gleitkomma-Einheit:

Das Datum wird ganzzahlig ab dem jeweiligen Nullpunkt gezählt. Die Tageszeit wird als Nachkomma-Anteil dargestellt.
Die Tabelle zeigt den maximal darstellbaren Zeitraum, abhängig von Wortbreite und Genauigkeit:

Einheit = Tage
Wortbreite	Genauigkeit: sec
32 Bit	2.212*10⁷ s	256 Tage
64 Bit	7.422*10¹⁴ s	23.5 Mio Jahre
Wortbreite	Genauigkeit: ms
32 Bit	2.117*10⁷ ms	5.88 Stunden
64 Bit	7.247*10¹⁴ ms	22965 Jahre

● Tage als Einheit sind in der Anwendung anschaulicher als Sekunden oder ms.
Man muss Tage jedoch als Gleitkomma-Zahlen speichern, um auch die Zeit anzugeben.
● Das bedeutet wesentlich geringere Geschwindigkeit bei der Verarbeitung.
● Gleitkomma-Zahlen haben zwar einen sehr großen Werte-Bereich, dieser kann jedoch wegen der begrenzten Genauigkeit nur zu einem winzigen Teil ausgenutzt werden.

● Die Tageszeiten 00:00, 12:00 und 24:00 entsprechen den Zahlenwerten 0.00, 0.50 und 1.00

Gleitkomma-Zahlen nach Standard → IEEE-754 bieten bei einem Wertebereich von 10^38.53 @ 32 Bit bzw. 10^308.3 @ 64 Bit und eine Genauigkeit von 24 bzw. 53 Bit.
Damit steht schon bei 32 Bit Wortbreite (Single) theoretisch mehr Zeit in Tagen zur Verfügung als das Alter des Universums.
Wenn man allerdings eine bestimmte Genauigkeit (Sekunden oder ms) fordert, dann wird der Bereich stark eingeschränkt.

Die Obergrenze ist so definiert, dass sich an diesem Datum gerade noch eine Zeit-Differenz der geforderten Auflösung (1 sec, 1 ms..) unterscheiden lässt.

Der Software-Marktführer verwendet Tage als Einheit mit 64bit-Double Gleitkomma-Zahlen und ms-Auflösung:
Windows-Betriebssysteme, Windows-Dateisysteme, das ↓ Y1900-System, das fast identische ↓ Y1904-System

Auch die meisten Systeme für historische oder astronomische Zwecke verwenden Gleitkomma-Tage. Allerdings stellen sie keine ausdrücklich formulierten Bedingungen an Genauigkeit oder Speicherform - Ihre Implementierung in der Informatik ist daher freibleibend.
Beispiel: Julischer Tag (↓ JD und ↓ MJD)

♦ Details zu IEEE-754 Gleitkomma-Zahlen und zu den Grundlagen ( Mantisse und Exponent)

Strukturen ganzer Zahlen {YYYY,MM,DD,hh,mi,ss}
Eine Datum-Zeit-Struktur enthält z.B. 6 zusammengehörende ganze positive Zahlen. Es ist übersichtich und einfach, Datum und Zeit als Strukturen abzubilden (Beispiel rechts), bzw. als Klassen zusammen mit den dafür benötigten Methoden zu kapseln. Dieses System lässt sich je nach Bedarf abkürzen oder durch ms (μs, ...) ergänzen. Der Transport zu anderen Systemen ist einfach und sicher.	struct datim { int year; int month; int day; int hour; int minute; int second; }
▼ Nachteil ist der sehr große Aufwand für jede Berechnung, insbesondere von Differenzen. Dazu braucht man in jedem Fall ein komplettes Kalender-Programm.	Strukturen werden daher nur als Klassen verwendet, zusammen mit den dafür benötigten Funktionen.
Als universelle Transportform hat die Struktur-Darstellung auf jeden Fall große Bedeutung. Damit ist man unabhängig von internen Datum-Formaten und fehler-anfälligen Text-Formaten. → XML (rechts) eignet sich besonders gut zur Formulierung von Strukturen. Transportieren sie Datum und Zeit - Daten im Zweifel in dieser Form ! Damit ist eine fehlerhafte Interpretation ausgeschlossen. ♣ Geben sie in Datum und Zeit - Daten wegen der kultur-spezifischen Unterschiede niemals Wochentag, Wochentag-Nummer oder Kalenderwoche an ! ♦ Details zum Thema Kalender	XML-Beispiel mit Live-Daten in Weltzeit UTC: <date> <year>2000</year> <month>1</month> <day>1</day> </date> <time zone="utc"> <hour>0</hour> <minute>0</minute> <second>0</second> </time>
Programmierung von Datum-und-Zeit - Strukturen: C/C++, Javascript, Perl, PHP, VBA

UNIX-Timestamp: Sekunden Weltzeit seit 1970-01-01 00:00:00
▲ Der Nullpunkt dieser Zeitskala liegt bei 1970-01-01 00:00:00 ▲ Als Einheit wird die Sekunde verwendet (Varianten mit 1 ms = 1/1000 sec) ▲ Die Skala arbeitet kontinuierlich und berücksichtigt keine (allfälligen) Schalt-Sekunden.	Dieser Standard wird generell auf Unix-(Linux)-Systemen und in allen modernen Programmiersprachen verwendet. Der größte Vorteil ist die hohe Geschwindigkeit der Verarbeitung. Intel-Prozessoren >Pentium bieten zur Verarbeitung von Timestamps sogar einen eigenen (Hardware) - TimeStampCounter.
Rechts Live Datum und Zeit des Webservers als Unix-Timestamp (Weltzeit → UTC).	2000-01-01 12:34:56 Lokalzeit CET 2000-01-01 12:34:56 Weltzeit UTC 1234567890 Timestamp (UTC)
Timestamps lassen sich ausgezeichnet speichern, transportieren und umwandeln. Man kann einfach und besonders rasch damit rechnen. Alle modernen IT-Systeme verwenden Timestamps.	UNIX-Timestamps werden grundsätzlich immer in Weltzeit UTC angegeben und erwartet. Ob tatsächlich → UTC oder die lokale Zeitzone verwendet wird, fällt in die jeweilige Verantwortung !
Der darstellbare Zeit-Bereich hängt von der verwendeten Technik ab. • Mit 32bit positiven Ganzen Zahlen (unsigned integer) liegt die Obergrenze theoretisch bei 19070-01-01 + 2^32 sec = 2106-02-07 • Ältere Systeme verwenden Standard Ganze Zahlen mit Vorzeichen (signed integer), dort liegt die Obergrenze (derzeit praktisch) bei 1970-01-01 + 2^31 sec = 2038-01-19	Das manchmal beschworene Jahr-2038-Problem wird allerdings nicht eintreten: Bis dahin wird es die heutigen 32-bit PC höchstens noch im Museum geben. • Größere Wortbreite: Die jetzt erhältliche PC-Generation verwendet bereits 64bit Worte. Beim einfachen Kopieren von Timestamp-Daten auf solche PC ist das Problem gelöst, denn 64bit Worte erweitern den Zeit-Bereich ohne Änderung der Daten auf >500 Mia Jahre. Probleme können sich evtl. bei Geräten ergeben, in welche Unix-Systeme fix eingebaut sind. Derart langlebige Geräte sind jedoch in unserer Gesellschaft kaum am Markt ... • Höhere Genauigkeit: Sekunden als Speicherform werden früher oder später durch kleinere Einheiten abgelöst, z.B. ms oder μs. Solche Timestamps erfordern eine Umrechnung (Faktor 1000 oder 1 Mio). • Javascript (ihr Browser) zeigt schon heute, wie das problemlos funktioniert.
Algorithmen (ohne Gewähr): M$-Software verwendet fast immer das Y1900-Format, und zwar ohne nähere Angaben meist in Lokalzeit. Beispiel für ein Standard Kalkulations-Programm (LibreOffice, OpenOffice, MS-Excel, ...): Tragen sie die Formel =JETZT() in eine Zelle ein und formatieren sie die Zelle im 'Standard'-Format. Weltzeit UTC aus der mitteleuropäische Zeit CET (MEZ), im Y1900-Format (Windows): utc = y1900 - 1/24 {bei Normalzeit} utc = y1900 - 2/24 {bei Sommerzeit} y1900 = utc + 1/24 {bei Normalzeit} ♣ Tipp: Die aktuelle Zeit-Differenz kann man aus der Registry-Datenbank lesen, für jedes andere Datum muss man sie (nur auf Windows) selbst berechnen. ▲ Vorsicht - Die USA verwenden andere Daten zur Sommerzeit-Umstellung (daylight savings) als die EU und die meisten anderen Staaten der Welt.	Unix Timestamp uts aus der Y1900 Weltzeit UTC: uts = (y1900_utc - 25569) * 86400 y1900_utc = uts / 86400 + 25569 Anzahl der Sekunden / Tag: 606024 = 86400 UNIX Start-Datum 1970-01-01 = 25569 als Y1900-Datum Diese Umrechnung kann man im Bereich 1970-01-01 bis 2038-01-18 uneingeschränkt verwenden. Wenn man für den Unix Timestamp auch negative Werte zulässt, dann ist die Rechnung ab >1900-03-01 brauchbar. Bei Daten <1900-03-01 hat der M$-Kalender einen jahrelang nicht behobenen Fehler von 1 Tag. Wenn man nur für Daten <1900-03-01 rechnet uts = (y1900_utc - 25568) * 86400 und außerdem negative Y1900-Werte zulässt, dann kann man den Bereich bis zur Einführung des gregorianischen Kalenders ausgedehnen, das ist in Mitteleuropa >1582-10-15, in den USA >1752-09-14 Wenn man für den Unix Timestamp Werte >2^31 zulässt, dann fällt auch die Obergrenze. Sie ist auf in M$-Software aus unerklärten Gründen willkürlich mit <10000-01-01 festgelegt. → Javascript verwendet Timestamps in Millisekunden. In diesem Fall ersetzen sie in den angegebenen Formeln uts durch (uts/1000)
Timestamp an der Linux-Konsole So wird die aktuelle Zeit als Unix-Timestamp an einer Linux Shell-Konsole angezeigt: # date "+%s"	Timestamp an der Windows-Konsole Der führende IT-Konzern hat naturgemäß kein Interesse, den UNIX Timestamp zu unterstützen. Das Programm → Cygwin portiert zahlreiche nützliche Linux Konsolen-Programme auf Windows, darunter auch date Damit kann man zahlreiche Datum- & Zeit-Formate anzeigen, natürlich auch den UNIX-Timestamp. ♦ Details zu Datum & Zeit mit Cygwin
♦ Details zum UNIX-Timestamp in verschiedenen Programmiersprachern: Perl, PHP, Javascript, SQL, VBA

Julian Day (JD) und Modified Julian Day (MJD)
Dieser Standard wird vorwiegend für astronomische und historische Daten verwendet. Das System wurde von Joseph Justus Scaliger (1540-1609) entwickelt und von John W. F. Herschel 1849 publiziert. Dabei handelt es sich um eine revolutionäre Idee: Es ist das erste "IT-taugliche" Datum-System, da es Datum und Zeit mit einer einzigen Zahl beschreibt, und man damit rechnen kann. Das Julianische Datum JD wird in der Astronomie allgemein verwendet und eignet sich in der Informatik zur Darstellung von Datum+Zeit über sehr lange Zeiträume. ▲ Der Nullpunkt (s.u.) für JD liegt bei -4712-01-01 (Scaliger-Tag) und umfasst damit die meisten historischen Daten. Der Nullpunkt kann übersprungen werden, d.h. man kann problemlos auch mit negativen JD rechnen. ▲ Der JD beginnt am Mittag (!) eines Tages und dauert bis zum Mittag des nächsten Tages. ▲ Die verwendete Einheit sind Tage, d.h. der Betrag von JD nimmt pro Tag um +1 zu. ▲ JD und MJD werden in Weltzeit → UTC angegeben. JD-Daten sind daher weltweit eindeutig sowie unabhängig vom Ort (→ Zeitzone) und von politischem Einfluss (→ Sommerzeit).	● Die JD-Skala ist kontinuierlich ohne Lücken und eignet sich daher ideal für (astronomische) Rechnungen. ● Die Genauigkeit ist nicht vorgegeben und richtet sich nach der Anwendung. Hohe Genauigkeit erfordert einfach mehr Speicherplatz. ● Bei der Umrechnung in Kalender ist zu beachten, dass diese Unstetigkeiten aufweisen. Im Julianischen Kalender gibt es kein Jahr 0: Auf -0001-31-12 folgt +0001-01-01 Bei der Umstellung auf den Gregorianischen Kalender wurden 10 Tage ausgelassen: Auf 1582-10-04 folgt 1582-10-15 Andere Staaten führten den Gregorianischen Kalender erst viel später ein, z.B. die USA: Auf 1752-09-02 folgt 1752-09-14 ● Von Julius Cäsar bis 1582 wurde der Julianische Kalender verwendet. Ältere Daten vor dem Nullpunkt unserer Jahres-Zählung werden ebenfalls oft mit diesem (proleptischen) Kalender beschrieben. Er weist jedoch einen systematischen Fehler auf. Über lange Zeiträume wirkt sich das stark aus. Es macht daher wenig Sinn, Daten von Jahren <-1000 so anzugeben. Man berechnet besser den Frühlingspunkt (Tag- und Nachtgleiche am 21.März) und gibt das Datum relativ dazu an. Das ergibt eine halbwegs realistische Interpretation von der Jahreszeit sehr weit zurückliegender JD-Daten.
● Der Modified Julian Day MJD ist ein bequemerer Zahlenwert, der sich durch Subtraktion aus dem JD ergibt. MJD = JD - 2400000.5 Die Idee zum MJD stammt aus dem Internationalen Geophysikalischen Jahr (1957/58). Das MJD wird in den Geo-Wissenschaften und teilweise in der Raumfahrt verwendet. MJD-Tage dauern so wie die Gregorianischen Tage von 0:00 bis 24:00 und sind daher für neuere historische Zwecke besser geeignet.	▲ Der Nullpunkt der MJD-Skala liegt damit am 1858-11-17 ▲ Mit 5stelligen ganzen Zahlen 00000 .. 99999 beschreibt MJD den Datum-Bereich 1858-11-17 .. 2132-08-31 ▲ Das MJD kann bei Bedarf auf Gleitkomma-Zahlen erweitert werden und so auch die Tageszeit darstellen. Der weltgrößte IT-Konzern wäre gut beraten gewesen, dieses bereits eingeführte System für sein internes Datenformat zu adaptieren. Das tatsächlich verwendete System ↓ Y1900 weist gegenüber MJD keine erkennbaren Vorteile auf.
Joseph Justus Scaliger (1540-1609) war ein italienisch-französischer Historiker. Bei seinen Recherchen erwies sich als besonders störend, dass vor der → gregorianischen Kalender-Reform das Datum in jeder kleinen Stadt anders gezählt und berechnet wurde. Man beschrieb die Jahre meist nach der Regierungszeit (lokaler) Herrscher, manchmal nach → Indiktionen, oft gänzlich chaotisch. Scaliger entwickelte eine kontinuierliche Skala vergleichbarer Datum-Zahlen, auf welche er alle historischen Daten zurückführen konnte. Er benannte sein System vermutlich nach seinem Vater Julius.	Auf der Suche nach einem geeigneten → Nullpunkt ging er systematisch vor: Am -4713-01-01 (Scaliger-Tag) treffen der 28-Jahre Sonnenzyklus (gleiche Wochentage am Monatsanfang), der 19-Jahre→ Metonische-(Mond)-Zyklus und der 15-Jahre→ Indiktions-Zyklus zusammen. Der Zeitpunkt lag weiter zurück als das von Scaliger angenommene Alter der Welt. Daher ergaben sich für alle damals bekannten historischen Daten positive JD-Zahlenwerte.
Das Live-Datum (des Webservers) als JD und MJD:	Weltzeit UTC: 0000-00-00 12:34:56 JD (UTC) = 1234567.12345 MJD = 12345
Ein praktisches Beispiel: 1705 berechnete Edmiond Halley 'seinen' berühmten Kometen. Er fand eine Umlaufzeit von 76.0057 Jahren und sagte das nächste Erscheinen (Perihel) für 1758-02-01 richtig voraus. Wann wird der Komet wieder sichtbar ?	jd(1758-02-01) = 2363188 Umlauf-Tage = 76 * 365.25 = 27761.1 Fortgesetzte Addition von 27761 zu 2363188 ergibt 2390949, 2418710, 2446471, 2474232, .. Diese JD-Werte ergeben nach Rückwandlung die nächsten Kometen-Termine: 1834-02-04, 1910-02-07, 1986-02-09, 2062-02-11, ...
Programmierung von JD und MJD: Für moderne Programmiersprachen wie Java, Perl, PHP gibt es im Internet kostenlose Module mit allen JD-Funktionen. ● Im Internet findet man zahlreiche Beispiele für Algorithmen (Rechen-Vorschriften) zur Umrechnung von / auf JD und MJD. ● Einige Webs bieten Live-Umrechnung von /auf JD und MJD an.	● Jedes ernstzunehmende Astronomie-Programm beherrscht und verwendet JD. Man findet dazu im Internet zahlreiche Freeware-Beispiele. ● Die Schwierigkeit bei der Umrechnung ist die Berücksichtigung der Schalttage und der "fehlenden" 10 Tage vor dem 1582-10-15, bei der Umstellung auf den gregorianischen Kalender. ♦ Details zur Programmierung: Javascript, VBA
Algorithmen (ohne Gewähr): In den meisten Quellen sind Algorithmen angeführt, welche die Umrechnung mit den Kalender-Elementen (Jahr, Monat, ...Sekunden) durchführen. Wenn man sich auf 'heutige' Zeiträume beschränkt (was in der Praxis meist der Fall ist), dann lässt sich die Umrechnung wesentlich rascher und einfacher direkt aus einem Unix Timestamp oder aus einem Y1900-Datum durchführen. Weltzeit Lokalzeit (Y1900) muss zuerst in Weltzeit UTC umgerechnet werden (↑ Unix Timestamp).	JD und Unix Timestamp jd = uts / 86400 + 2440587.5 uts = (jd - 2440587.5) * 86400 Diese Umrechnung kann man im Bereich 1970-01-01 bis 2038-01-18 uneingeschränkt verwenden. Wenn man negative Zahlen und Timestamp-Werte >2^31 zulässt, dann sind die Grenzen nur durch den Kalender gegeben. JD und Y1900-Datum (in Weltzeit) jd = y1900 + 2415018.5 y1900 = jd - 2415018.5 Diese Umrechnung kann man im Bereich 1900-03-01 bis 9999-12-31 uneingeschränkt verwenden.
Links zum Thema "Julian Day": Hermetic Systems, Peter Meyer (en)	Live-JD Berechnung: FU Berlin (de) Numerical Recipes (en)

Das Y1900-Datumsystem: Tage seit 1899-12-30 00:00:00
▲ Dieses System zur Darstellung von Datum und Zeit verwendet 'ungefähr' den 1900-01-01 als Nullpunkt und 1 Tag als Einheit. Der Zahlenwert nimmt daher um +1 pro Tag zu. ● Wegen eines jahrelang (und weiterhin) unkorrigierten M$-Fehlers legt man den Nullpunkt heute aus praktischen Gründen auf 1899-12-30. ● Die Zeit kann als Nachkomma-Anteil dazugefügt werden. ● Wie auch in anderen Fällen verwendet M$ keinen etablierten Standard (↑ JD seit 400 Jahren bewährt), sondern ein eigenes System, und zwar - wie meistens - mit besonderen Nachteilen gegenüber dem Standard.	M$ verwendet das Y1900-System in seinen Betriebssystemen und Software-Produkten inkl. → Visual Basic (VBA). OpenOffice verwendet ebenfalls dieses System - jedoch ohne den M$-Fehler und mit einem größeren Bereich.. Das Y1900-System wird gelegentlich auch als 'Dubliner Julianisches Datum (DJD)' bezeichnet. M$-Excel für MacOS verwendet aus einem unbekannten Grund ein etwas abweichendes System mit Nullpunkt 1904-01-01.
Grenzen: Y1900 definiert eine Skala für Datum und Zeit, jedoch keine Grenzen. Selbstverständlich ist es möglich, auch mit negativen Zahlen zu rechnen, diese entsprechen Tagen vor dem 1899-12-30. Das ist in modernen Programmen realisiert: OpenOffice verwendet das Y1900-System und kann mit den Jahren 1 bis 32767 (richtig !) rechnen. Damit ist es nicht nur mit M$ kompatibel, sondern dem M$-System weit überlegen. OpenOffice eignet sich daher (im Gegensatz zu M$) gut für die meisten historischen Daten.	M$-Programme begrenzen das verwendbare Datum aus unbekannten Gründen: Das M$-Y1900-System kann nur von Jahr 1900-9999 rechnen. Die Obergrenze stellt kein Problem dar, die Untergrenze schließt jedoch die meisten historischen Daten aus. Immerhin beherrschen M$-Programme bereits das Rechnen mit (anderen) negativen Zahlen ...
Kritische Daten: Ein guter Kalender muss alle Regeln des geltenden Gregorianischen Kalenders beherrschen. ● Seit der Kalender-Reform im Jahr 1582 sind eigene Schalttag-Regeln für jedes 4., 100. und 400. Jahr zu berücksichtigen. ● Bei der Reform sind die Tage 1582-10-05 bis 1582-10-14 ausgefallen, auf 1582-10-04 folgt daher 1582-10-15. ● Vor 1582 gilt der Julianische Kalender mit Schalttagen nur alle 4 Jahre. Moderne Programme haben damit kein Problem. OpenOffice rechnet für alle Daten seit dem Jahr 1 richtig.	Der von M$ verwendete Kalender enthält seit vielen Jahren einen Fehler: M$ zählt den 1900-02-29 als 60. Tag. - Diesen Tag hat es nie gegeben, weil der Schalttag in diesem Jahr ausgefallen ist. ● Für aktuelle Daten verwendet M$ daher in Wirklichkeit nicht das Y1900-System sondern ein 1899-12-30-System. Immerhin ist es ab Tag Nr. 61, d.i. 1900-03-01 mit dem üblichen Y1900-System identisch.
Das Live-Datum des Webservers im Y1900-Format in Weltzeit (UTC). ► Kontrolle: Geben sie in OpenOffice oder Excel die Formel =JETZT() in eine Zelle ein und formatieren sie die Zelle als Standard-Zahl. Das Y1900-Datum in PC-Lokalzeit wird angezeigt.	Lokalzeit: 0000-00-00 12:34:56 Weltzeit UTC: 0000-00-00 12:34:56 Y1900 (Lokalzeit) = 12345.12345 Y1900 (UTC) = 12345.12345
Zeitzonen und Weltzeit UTC M$ bemüht sich, dieses Thema von seinen AnwenderInnen fernzuhalten. Es gibt kaum Unterstützung zur Umwandlung von Zeit-Daten in andere Zonen oder in Weltzeit UTC. Berechnungen über die Grenzen von Normalzeit / Sommerzeit sind unsicher und oft fehlerhaft. Die wenigen brauchbaren Funktionen sind meist gut versteckt. Offenbar hält man die AnwenderInnen für zu dumm, um mit Zeitzonen umzugehen.	Das ist in einer globalisierten Welt ein erhebliches Problem. Immerhin erstreckt sich die EU über 3 Zeitzonen. ♣ Tipp: Wenn Daten international verwendet werden, dann sollte man dazu immer die Zeitzone angeben. Am besten geeignet ist Weltzeit UTC, denn sie kennt keine Sommerzeit, daher ist ein Datum nur in diesem Fall wirklich zuverlässig und weltweit eindeutig.
Programmierung (Umwandlung) des Y1900-Datum-Systems: Javascript, VBA	Windows-Konsole Eine Ausgabe des aktuellen Y1900-Datums an der Konsole cmd.exe ist nicht vorgesehen. Mit → Cygwin kann man dafür ein Mini-Programm erstellen. Auf Linux ist das Y1900-Format entbehrlich. ♦ Details zu Datum und Zeit mit VBA und Cygwin

Sonder-Formate
ANSI Das ANSI-Datum dient zur Datum-Zählung in der klassischen, aber heute kaum mehr verwendeten Programmiersprache COBOL. Nullpunkt ist 1601-01-01	Military-'JahrTag' In manchen militärischen Bereichen hält sich noch immer eine exotische Form der Datum-Angabe: (Letzte Ziffer des Jahres)1000 + TagDesJahres z. B. für heute 0 1000 + 000 = 0000
FileMaker stellt ausgezeichnete Datenbank-Systeme her. Dabei wird ein eigenes System für Datum und Zeit verwendet. Das Datum wird ganzzahlig in Tagen (ungefähr) seit 01-01-01 gezählt (ähnlich wie bei ↑ Y1900 und ↑ JD). Historische Daten >1582-10-14 können verwendet werden. Leider ist die Gregorianischen Kalender-Reform 1582 nicht berücksichtigt. Daher weist der Kalender bei älteren Daten Fehler (!) von 1..10 Tagen auf, ohne daß dies ausgewiesen wird. Die Zeit wird ganzzahlig in Tages-Sekunden von 0 bis 246060=86400 geführt.	In neueren FileMaker-Versionen ist zusätzlich der ganzzahlige Datentyp 'Zeitstempel' verfügbar. Der Nullpunkt dieses Systems liegt ebenfalls (ungefähr) bei 01-01-01, Skalen-Einheit ist die Sekunde (wie im ↑ UNIX-Timestamp), der Kalender-Fehler vor 1582-10-14 ist der gleiche. ♦ Details zur Programmierung der Filemaker-Datenformate: Javascript

M$ Sonder-Formate
Für spezielle Zecke (z.B. Zeit-Synchronisation mit → NTP) werden auf Windows auch andere interne Formate verwendet.	Man findet in der Registry-Datenbank ungewöhnliche Zeit-Marken, z.B. in den hier beschriebenen Formaten (ohne Gewähr).
Das 100ns-Format Einige Zeit-Angaben der Registry Datenbank enthalten viel größere Zahlen als das Y1900-Format zulassen würde, meist in hexadezimaler Notation. Nullpunkt: 1600-01-01 00:00:00 Einheit 100ns = 10-7 sec Die Skala 'verwendet' den notorischen M$ Fehler am niemals stattgefundenen Tag 1900-02-29 Sie lässt sich daher direkt in Y1900-Werte umrechnen, ist jedoch für alle Daten vor dem 1900-02-28 um einen ganzen Tag falsch - d.h. für ca. 3/4 der seit dem Nullpunkt im Jahr 1600 abgelaufenen Zeit. Es fehlen keine Tage zwischen 1600 und 1900, d.h. man rechnet offenbar mit dem Gregorianischen Kalender und nicht mit dem US-Kalender, der erst 1752 umgestellt wurde. Bei der Ausgabe sollte man nur die Angabe in UTC (Weltzeit) berücksichtigen. Die nachfolgende Angabe in Lokalzeit berücksichtigt offenbar nicht das Datum, sondern nur die aktuell am PC eingestellte Zeit. Daher sind Lokalzeit-Angaben eines Sommer-Datums um 1 Stunde falsch, wenn sie im Winter berechnet werden, und umgekehrt.	Umrechnung Y1900 nach 100ns-Format: k1 = 8.64e+11 d1 = 9.43531e+16 f100n = Y1900 * k1 + d1 Umrechnung 100ns-Format nach Y1900 k2 = 1.15741e-12 d2 = -109205 Y1900 = f100n * k2 + d2 ♣ Verwenden sie zur Umwandlung Hexadezimal -> Dezimal z.B. den Rechner calc.exe mit Ansicht = Wissenschaftlich. ♣ Verwenden sie zur Umrechnung des 100ns-Format (dezimal) das Konsolen-Programm w32tm Beispiel: C:\> w32tm /ntte 125911584000000000 145731 00:00:00.0000000 - 01.01.2000 01:00:00 (local time) (Ergebnis für 2000-01-01 00:00:00 UTC, Ausgabe auf einem PC in Mitteleuropa) Die führende ganze Zahl (hier 145731) gibt die Anzahl der Tage seit 1600-01-01 an.
Das 2^24s-Format Manche Zeit-Angaben in Zusammenhang mit dem NTP Protokoll zur Zeit-Synchronisation werden in einem ungewöhnlichen Format angegeben: Nullpunkt: 1900-01-01 00:00:00 Einheit 2^24s = 16777216s = 194.180741 Tage Die Skala enthält keinen Fehler. Es ist eigenartig, dass sich im Umrechnungs-Programm w32tm /ntpte nur ganze Zahlen eingeben lassen. Das Beispiel rechts zeigt den Zeitpunkt mit Einheit 189, welcher 2000-01-01 am nächsten kommt. ♣ Hinweis: Die Hilfe zum verwendeten Konsolen-Programm dürfte einige Fehler enthalten. C:\> w32tm /? ♦ Details zur Zeit-Synchronisation von Windows-PC (u.a. mit dem Programm w32tm ).	Umrechnung Y1900 nach 2^24s-Format: k3 = 0.005149841 d3 = -0.010299683 f224 = Y1900 * k3 + d3 Umrechnung 2^24s-Format nach Y1900 k4 = 194.1807407 d4 = 2 Y1900 = f224 * k4 + d4 ♣ Verwenden sie zur Umrechnung des 2^24s-Formats (dezimal) das Konsolen-Programm w32tm Beispiel: C:\> w32tm /ntpte 189 0x01BFDE587DE04000 - 29351512 145907:03:50:00.0000024 - 25.06.2000 04:50:24 (local time) (Ausgabe auf einem PC in Mitteleuropa) Die führende Hex-Zahl gibt den gleichen Zeitpunkt im 100ns-Format ↑ an, das entspricht C:\> w32tm ntte 126063786240000000 Die Bedeutung der folgenden ganzen Zahl (hier 29351512) ist unklar, sie nimmt mit jeder 2^24s Einheit um 39062 oder 39063 zu. Die nächste ganze Zahl hat die gleiche Bedeutung wie im 100ns-Format ↑

Ausgewählte Links zum Thema 'Datum und Zeit'
uhrzeit.org (de) wiki NTP webhome (en) US Naval Observatory (USNO)	Metrologie.at (de) Calendarzone
Aktuelle Zeit - Achtung, z.T. in UTC !) PTB Braunschweig (de) uhrzeit.org (de) BIPM (fr) auch für FTP - Protokoll USNO (en) USA NIST (en) Colorado, USA	Glossary of Frequency and Timing Terms FAQs des NIST Colorado, USA Yahoo Science: Measurements and Units: Time Links U.S. Naval Observatory USNO International Earth Rotation Service (IERS) Network Time Protocol (NTP) USENET sci.astro FAQs Tondering Calendar FAQs Univ. Delaware (EECIS) Wilson Mar: Date, Time & Calendar Functions
IETF: RFC3161 (Timestamp Protocol)	Zeitstempel (Timestamp), Unixzeit, Julianisches Datum,

Datum & Zeit	Schnittpunkt von uralter Kultur und Informationstechnik
Interne Darstellung von Datum und Zeit
Allgemein	Wortbreite, Nullpunkt, Skalen-Einheit
Struktur	Struktur ganzer Zahlen {YYYY,MM,DD,hh,mi,ss}
UNIX Timestamp	Sekunden seit 1970-01-01
JD und MJD	Skala für astronomische und historische Daten
Y1900	Tage seit 1900-01-01, Variante 1904-01-01
Sonderformate	ANSI-Cobol (1601-01-01), Military, FileMaker (01-01-01)
M$ Sonderformate	Intervalle von 10^-7 sec und 2⁺²⁴ sec
Live	Umrechnung verschiedener interner Daten-Formate
Text-Standards	ISO-8601, DIN-5008, RFC-822
Datum & Zeit in Programmiersprachen:
Javascript	Das Timestamp-ms-System von JS und einige Funktionen
Perl	Perl-Funktionen für Datum und Zeit
PHP	PHP-Funktionen für Datum und Zeit
SQL	SQL-Feldtypen und Funktionen für Datum und Zeit
VBA	Das Y1900-System von M$ und einige Funktionen
Links	Ausgewählte Links zum Thema 'Datum und Zeit'

Interne Formate für Datum und Zeit

Systeme zum Speichern und Rechnen

Interne Darstellung von Datum und Zeit

Sekunde oder Millisekunde (ms) als ganzzahlige Einheit:

Tag als Gleitkomma-Einheit:

Strukturen ganzer Zahlen {YYYY,MM,DD,hh,mi,ss}

UNIX-Timestamp: Sekunden Weltzeit seit 1970-01-01 00:00:00

Timestamp an der Linux-Konsole

Timestamp an der Windows-Konsole

Julian Day (JD) und Modified Julian Day (MJD)

Programmierung von JD und MJD:

Das Y1900-Datumsystem: Tage seit 1899-12-30 00:00:00

Grenzen:

Kritische Daten:

Zeitzonen und Weltzeit UTC

Windows-Konsole

Sonder-Formate

ANSI

Military-'JahrTag'

FileMaker

M$ Sonder-Formate

Das 100ns-Format

Das 2^24s-Format

Live-Umrechnung einiger Datum-Zeit-Systeme

Ausgewählte Links zum Thema 'Datum und Zeit'

Aktuelle Zeit - Achtung, z.T. in UTC !)