Datums und Zeitwerte

[Ghostwalker]

Mal ganz allgemein gefragt, wie speichert ihr Datums und Zeitwerte in einer Datenbank ?

[Der schöne Günther]

Jedes DBMS das ich kenne (bzw das TDataSet von Delphi) hat einen passenden Typ (bzw.AsDateTime-Property für die Felder). Wie das intern gelöst wird muss einen doch gar nicht interessierw, oder?

[TigerLilly]

Technisch: Den passenden Datentyp benutzen, den das DBMS bietet.

Fachlich: Da sind Datum + Zeit oft schwierig, weil man sich überlegen muss, ob man beim Datum den Zeitanteil dabei haben will bzw mit welcher Genauigkeit. Zeitzonen sind da auch ein Thema (ev siehe auch UTC).

[p80286]

Ich muß zu meiner Schande gestehen daß mich das nie gejuckt hat. Der DB-Server hat(te) eine Zeitzone und gut war's. Mittel- und West-Europa sowie USA Ost und West-Küste passten knapp unter einen Hut, die täglichen Jobs liefen ab 4:00 Uhr und gut war's.
Ein Problem wird China werden, weil dann der Slot für die Jobs wegfällt. Aber die Zeitangaben waren nie ein Problem, weil eigentlich nur der relative Abstand der Datenmanipulationszeitpunkte zueinander interessiert. da ist es uninteressant ob die Server-Zeitzone GMT, UTC oder PST ist.

Gruß
K-H

[Schokohase]

Zitat:

Zitat von p80286 (Beitrag 1412295)

Aber die Zeitangaben waren nie ein Problem, weil eigentlich nur der relative Abstand der Datenmanipulationszeitpunkte zueinander interessiert. da ist es uninteressant ob die Server-Zeitzone GMT, UTC oder PST ist.

Genau, das Problem hat man ja nur an den Tagen wo die Zeitumstellung erfolgt und man den relativen Abstand zwischen Datenmanipulationspunkten bestimmen möchte, wo ein Zeitpunkt Winterzeit und der andere Sommerzeit ist.

Lustig wird es, wenn auf Winterzeit zurückgestellt wird und es ein bestimmtes Zeitfenster doppelt gibt. Dann berechne mal korrekt deinen relativen Abstand.

Ist 02:31-02:32 jetzt 1 Minute oder 61 Minuten?

[p80286]

Jain, zum Einen gibt es nur die Serverzeit, zum Anderen, hat irgendjemand gesagt, daß diese Zeitumstellerei mitgemacht werden muß?

Was juckt den Server ob es 7:00 oder 19:00 Ortszeit ist? Seine Zeitpunkt ist 8:00.

Gruß
K-H

[himitsu]

[deleted]

[mensch72]

.."Jedes DBMS das ich kenne (bzw das TDataSet von Delphi) hat einen passenden Typ (bzw.AsDateTime-Property für die Felder). Wie das intern gelöst wird muss einen doch gar nicht interessierw, oder?"...

Leider doch, denn es gibt kaum ein DBMS, welches historisch stets richtig UTC Zeiten in die am jeweiligen Datum für eine bestimmte Zeitzone korrekt ausgibt und dazu via SQL noch intern korrekt Offsets dazu oder weg rechnen kann.

Einfache DBMS scheitern ja schon bei UTC Timestamps in der Tabelle, wenn die US Sommerzeit anders beginnt als die EU Sommerzeit. Wenn es aktuell geht, kapieren bestimmte Systeme einfach nicht das die erst seit Jahr XXXX gilt und es davor anders war... also auch wenn aktuell alles stimmt sollte man wenn es eine globale Anwendung mit auch historischen Daten ist, wirklich selbst alles sehr sehr genau testen, bzw. doch auf eine eigene Variante setzen.

Beispiel "SAP Zeitmodell":
https://help.sap.com/doc/abapdocu_75...zone_rules.htm
Das SAP Konzept ist gut und sehr universell, aber auch sehr langsam wenn es um Millisekunden geht, im HFT-Finanzbereich kommen zeit&speicher optimiertere Methoden zum Einsatz. Eigene ConvertTo/ConvertFrom sind dann die möglichst selten genutzen Funktionen um letztendlich wieder alles in StandardDBs zu speichern oder via Standard-GUIs/Reports zu visualisieren.

[Mavarik]

Zitat:

Zitat von Schokohase (Beitrag 1412296)

Ist 02:31-02:32 jetzt 1 Minute oder 61 Minuten?

Deswegen speichert man Serverseitig immer UTC.

Zitat:

Zitat von p80286 (Beitrag 1412299)

Was juckt den Server ob es 7:00 oder 19:00 Ortszeit ist? Seine Zeitpunkt ist 8:00.

Kommt darauf an, wer die Zeit erzeugt hat.