Datum & Zeit in Datenbanken
|
In fast allen Datenbanken werden auch Datum & Zeit - Daten verwaltet.
Dabei sollen z.T. widersprüchliche Anforderungen erfüllt werden:
▲
Die Lösung muss den bestehenden und den erwarteten Datum-Bereich abdecken
(Erinnerung an das 'Jahr-2000-Problem' !).
▲
Der Datenfluss von und zur Datenbank muss mit allen verwendeten und
voraussehbaren Technologien und Daten-Formaten problemlos und rasch funktionieren.
|
▲
Die Lösung soll einfache Rechnungen erlauben.
▲
Die Interpretation der Daten muss weltweit eindeutig sein, unabhängig
von Sprache, Kulturkreis und Zeitzone.
Das alles klingt recht trivial.
Der Teufel verbirgt sich
- wie immer -
im Detail ...
|
Modell "Struktur":
Datum und Zeit wird in Form einer Struktur von 6 einzelnen ganzen Zahlen
gespeichert (Jahr, Monat, Tag, Stunden, Minuten, Sekunden, Differenz zur Weltzeit =
TimeZone Offset in Stunden).
Das aktuelle Datum in Weltzeit (!) UTC lautet
{yyyy,mo,dd,hh,mi,ss,1}
Diese Variante bietet maximale Kompatibilität, hohe Geschwindigkeit und
einen beliebig großen Datum-Bereich.
Ein besonderer Vorteil ist die Möglichkeit, unbekannte Datum-Teile mit 0
einzutragen (↓ Eingabe von
Datum & Zeit).
|
Allerdings sind in dieser Variante keine Rechnungen möglich:
Eine derartige Struktur kennt nicht die Logik von Stunden & Minuten,
schon gar keinen Kalender.
Datum-Rechnungen benötigen daher einen hohen Aufwand an externer Software,
und damit auch hohe Kosten.
Daher werden Datum & Zeit-Strukturen nicht als Speicherform verwendet,
sehr wohl jedoch zum Transport von Daten.
|
Modell "Zeitstempel"
Datum und Zeit wird gemeinsam in einer Zahl codiert.
Das entspricht am besten der Natur der Zeit, die bekanntlich kontinuierlich
abläuft.
●
Zum Rechnen genügen die 4 Grundrechnungs-Arten. Man braucht weder die
Algorithmen zur Umrechnung von Sekunden, Minuten und Stunden
(im uralten 60er-System) noch einen komplizierten Kalender mit ungleich
langen Monaten, Schalttagen usw.
Das ist nicht nur praktisch sondern viel schneller !
|
●
Allerdings muss jedes Datum bei der Eingabe in die interne Zahl umgewandelt
(codiert) und bei der Ausgabe wieder decodiert werden.
Jede Datenbank verwendet ein internes Format dieser Art zum Speichern
von Datum & Zeit.
Meist wird ein
→ UNIX Timestamp verwendet, seltener das
→
Y1900-System von Microsoft oder der
→
Julianische Tag (JD).
Alle gängigen Zeitstempel verwenden zumindest intern die Weltzeit
UTC (früher GMT).
|
Der UNIX-Timestamp
zählt die Sekunden
seit 1970-01-01 00:00:00 in Weltzeit (UTC), d.h.
ohne lokale Zeitzone oder Sommerzeit.
●
Mit ganzen Zahlen lässt sich besonders rasch rechnen.
Daher wird der ganzzahlige UNIX-Timestamp von allen Datenbanken und von jeder
modernen Programmiersprache unterstützt.
|
Der Timestamp wird als ganze Zahl mit 32 Bit (INTEGER)
formuliert.
1 Tag entspricht der Zahl 24*60*60=86400,
1 Stunde 60*60=3600,
1 Minute 60, usw.
Der aktuelle UNIX-Timestamp in Sekunden ist
uts = 0000000000
|
Texte (Strings)
Alle Datenbanken bieten die Möglichkeit, Datum- und Zeit-Daten
in Form von Strings (Texten) ein- und auszugeben. Das erlaubt den
Austausch praktisch beliebig formatierter Daten.
Allerdings stellen Datum-Strings gleichzeitig einen gefährlichen
Schwachpunkt dar: Die meisten älteren Formate sind historisch gewachsen,
daher selten einheitlich, von der lokalen Sprache und Kultur abhängig und
manchmal so chaotisch wie die vielen unterschiedlichen US-Datum und Zeit-Formate.
"mo/dd/yy
hh:mi:ss"
Die Angabe der Zeitzone ist in kleinen Kultur- und
Wirtschaftsräumen nicht notwendig und fehlt daher meist, sogar in der
heutigen globalisierten Welt.
|
Daher muss die Software meist Annahmen (!) treffen,
um eintreffende Datum-Strings richtig zu verstehen.
Solche Risken sind für wichtige Daten inakzeptabel. Daher sollte durch
zusätzliche (meist aufwändige) Maßnahmen garantiert werden,
dass die Datum-Strings eindeutigen Regeln folgen,
am besten dem weltweiten Standard
→ ISO-8601.
"yyyy-mo-dd
hh:mi:ss"
♣
Tipp: So bald wie möglich eine saubere Trennung herbeiführen:
• Strings (Texte) sind
für Menschen geeignet und eine Aufgabe der User Interface Programme.
•
In die Datenbank gehören keine Datum & Zeit-Strings sondern nur sichere,
eindeutige Daten wie z.B. Timestamps.
|
SQL @ MySQL
