Hallo,

Datums- und Zeit-Daten sind generell ein Problem. Sie können viele unterschiedliche Formate haben, es gibt verschiedene Zeitzonen und Sommer-/Winterzeit. Anwender machen gerne Fehler bei der Eingabe von Datums- und Zeit-Werten.

Ich möchte mich damit beschäftigen wie man professionell mit Datums- und Zeit-Werten umgeht. Insbesondere interresiert mich das auch in Bezug auf Datenbanken.

Die Datenbanken sollen ja konsistent bleiben. Auch dann wenn der Server oder die Software in eine andere Zeitzone zieht oder eine Zeitumstellung stattfindet.

- Kennt Ihr gute Artikel, Ebooks oder dergleichen, die dieses Thema ausführlich behandeln?

Am besten natürlich in Deutsch, aber Englisch ist auch OK.

Danke im Voraus.

Ich benutze bei PHP Projekten ADODB, die Schnittstelle konvertiert mir die Datums und Zeitfelder in das entsprechende Format der Datenbank. Für die Berechnung von Zeitwerten in der Software benutze ich dann UTC.

HTH Phil

Also Oracle bietet dafür einen eigenen datentyp an: Timestamp. Dieser enthält auch die Zeitzone (bei bedarf).

Ansonsten muss man sich das in der Tabelle selbst speichern in welcher Zeitzone das Datum eingegeben wurde und ggf. eine Umrechung vor die Anzeige schalten.

In diversen Foren kann man ja auch selbst wählen in welcher Zeitzone man sich befindet und wie die Zeit dementsprechend angezeigt werden soll.

Dim

Danke für eure Antworten.

Ich verfahre nun folgendermaßen. Alle Zeitdaten werden als UTC-Timestamp gespeichert.

Für die Ausgabe muss dann in die MEZ bzw. MESZ umgerechnet werden. Dazu habe ich folgende Stored Procedure für MySQL geschrieben:

CREATE FUNCTION sp_getDate(utcTimestamp DATETIME) RETURNS DATETIME


BEGIN


DECLARE mezTimestamp, beginnMESZ, endeMESZ DATETIME;

DECLARE temp VARCHAR(17);


SET beginnMESZ = STR_TO_DATE(CONCAT('31.03.', DATE_FORMAT(utcTimestamp,'%Y'), ' 02:00:00'),'%d.%m.%Y %H:%i:%s');


WHILE DAYNAME(beginnMESZ) != 'Sunday' DO

SET beginnMESZ = TIMESTAMPADD(DAY, -1, beginnMESZ);

END WHILE;


SET endeMESZ = STR_TO_DATE(CONCAT('30.10.', DATE_FORMAT(utcTimestamp,'%Y'), ' 04:00:00'), '%d.%m.%Y %H:%i:%s');


WHILE DAYNAME(endeMESZ) != 'Sunday' DO

SET endeMESZ = TIMESTAMPADD(DAY, -1, endeMESZ);

END WHILE;


SET mezTimestamp = TIMESTAMPADD(HOUR, 1, utcTimestamp);


IF mezTimestamp BETWEEN beginnMESZ AND endeMESZ THEN

SET mezTimestamp = TIMESTAMPADD(HOUR, 1, mezTimestamp);

END IF;


RETURN mezTimestamp;


END

Achtung, der Code ist nicht getestet!

Der folgende untere Code sollte jetzt fehlerfrei funktionieren. Jedenfalls laut diesen Testdaten:

MESZ 	UTC

NULL 	00.00.0000 00:00:00

30.03.2008 02:59:59 	30.03.2008 01:59:59

30.03.2008 04:00:00 	30.03.2008 02:00:00

30.03.2008 04:00:01 	30.03.2008 02:00:01

26.10.2008 05:59:59 	26.10.2008 03:59:59

26.10.2008 06:00:00 	26.10.2008 04:00:00

26.10.2008 05:00:01 	26.10.2008 04:00:01

CREATE FUNCTION sp_getDate(utcTimestamp DATETIME) RETURNS datetime

BEGIN


DECLARE mezTimestamp, beginnMESZ, endeMESZ DATETIME;

DECLARE temp VARCHAR(19);


SET beginnMESZ = STR_TO_DATE(CONCAT('31.03.', DATE_FORMAT(utcTimestamp,'%Y'), ' 02:00:00'),'%d.%m.%Y %H:%i:%s');


WHILE DAYNAME(beginnMESZ) != 'Sunday' DO

SET beginnMESZ = TIMESTAMPADD(DAY, -1, beginnMESZ);

END WHILE;


SET endeMESZ = STR_TO_DATE(CONCAT('30.10.', DATE_FORMAT(utcTimestamp,'%Y'), ' 04:00:00'), '%d.%m.%Y %H:%i:%s');


WHILE DAYNAME(endeMESZ) != 'Sunday' DO

SET endeMESZ = TIMESTAMPADD(DAY, -1, endeMESZ);

END WHILE;


SET mezTimestamp = utcTimestamp;


IF mezTimestamp BETWEEN beginnMESZ AND endeMESZ THEN

SET mezTimestamp = TIMESTAMPADD(HOUR, 1, utcTimestamp);

END IF;


SET mezTimestamp = TIMESTAMPADD(HOUR, 1, mezTimestamp);


RETURN mezTimestamp;


END

Hat jemand noch Vorschläge zur Vereinfachung oder Erweiterung? Des Weiteren gibt es noch die Möglichkeit bei jeder Clientverbindung die Zeitverschiebung einzustellen.

SET time_zone  = '+01:00';

Quelle1

Quelle2

Dann werden die Timestamp-Werte angeblich in automatisch UTC gespeichert und mit der entsprechenden Verschiebung ausgegeben. Allerdings gehe ich davon aus, dass die Verschiebung bei Sommerzeit nicht automatisch 2 Stunden beträgt. Das müsste man also doch selber regeln.

Außerdem wird dann wohl nur die aktuelle Zeit ungerechnet. Ältere Daten aus der DB werden wohl kaum auf Sommerzeit geprüft.