Calocybe: Rueckumwandlung einer Zeitangabe into Sekunden seit 1970

Beitrag lesen

Hi folks!

Ich will mal nach Eurer Meinung zu einem Problem, das ich gerade habe, fragen. Und zwar erarbeite ich noch ein paar Statistiken vom Forumsarchiv. Dazu will ich alle Datums-/Zeitangaben erstens in ein leicht verarbeitbares Format konvertieren (also Sekunden seit 1970) und zweitens alle Zeitangaben in dieselbe Zeitzone ansiedeln (was vom Forumsscript niedergeschrieben wird, wird ja in der jeweils aktuellen Zeitzone gerechnet, und das ist zur Winterzeit GMT+0100 und zur Sommerzeit GMT+0200). Als Zielzeitzone bietet sich da natuerlich GMT an, schon weil die Sekunden seit 1970 ueblicherweise in GMT gemessen werden.

Nun will ich das also zurueckrechnen. Dafuer bieten die verschiedenen Sprachen (hoffentlich) schon Funktionen an, in Perl z.B. ist dafuer das Modul Time::Local mit der Funktion timelocal() zustaendig. Doch um eine Zeitangabe korrekt zu interpretieren, muesste man da nicht erstmal wissen, in welcher Zeitzone diese Angabe gemacht wurde? Natuerlich, denn 1 Uhr in GMT+0100 ist ja schliesslich was anderes als 1 Uhr in GMT+0200 und wuerde einen anderen Sekunden-seit-1970-Wert ergeben. Im Date-Header von EMails findet man deswegen z.B. auch immer eine Zeitzonenangabe.

Wie macht das dann aber die genannte timelocal() Funktion? Die Antwort ist einfach, es richtet sich immer nach der momentan aktuellen Zeitzone, die problemlos vom Betriebssystem oder aus der Environment abgelesen werden kann. Das ist also far from perfect. Man ueberlege sich nur, ich waere jetzt an der Ostkueste der USA (imho GMT-0500) und wuerde Daten mitteleuropaeischer Zeit verarbeiten.

Nun hilft ja alles Gejammer nichts, schliesslich gibt es einen Job zu erledigen. Immerhin, es ist ja eigentlich bekannt, wann die Umstellung Sommerzeit/Winterzeit und umgekehrt erfolgt. Also koennte ich die Berechnung ja mit ein wenig Programmieraufwand korrigieren, indem ich z.B. vor dem zurueckrechnen mal eben die Zeitzone entsprechend aendere oder hinterher einen Offset auf das Ergebnis addiere. Aber, waere doch gelacht, wenn es da nicht auch Probleme gaebe.

Erstens ist es naemlich doch nicht ganz so bekannt, wann diese Umstellungen erfolgen. So gab es z.B. 1995 eine ausserordentliche Abweichung um glaube einen Monat, woraufhin die automatische Umstellung von Windows 95 versagte (eben 1 Monat zu frueh erfolgte) und allen moeglichen Zeitschriften Tips gegeben wurden, wo in der Registry die Daten der Umstellung kodiert sind und welche Aenderung man vornehmen muesste. Solche Abweichungen kann es in der Zukunft durchaus wieder geben, vielleicht wird ja sogar irgendwann die Sommerzeit wieder abgeschafft, was zu hoffen waere.

Zweitens wird am Tag der Umstellung von Sommer- zu Winterzeit der Bereich von 2 Uhr bis 3 Uhr zweimal durchlaufen, da um 3 Uhr Sommerzeit die Uhr um eine Stunde zurueckgekurbelt wird. Wenn man eine Zeitangabe aus diesem Bereich vorliegen hat, so gibt es imho keine Moeglichkeit festzustellen, ob das noch Sommerzeit oder schon Winterzeit ist. (Bei der Speicherung wurde ja eben diese Information weggeschmissen, und nun fehlt sie.) Bei der anderen Umstellung, von Winter- zu Sommerzeit, ist das nicht so problematisch, da wird diese Stunde uebersprungen, sodass theoretisch keine Zeitangaben zwischen 2 und 3 Uhr auftreten sollten. (Ein vernuenftiges Programm faengt den Fall natuerlich trotzdem ab.)

Mein Fazit: Immer alle Zeitangaben in GMT speichern, oder zumindest die jeweils verwendete Zeitzone mitnotieren.

Comments are welcome; So long