nicht angemeldet
Rueckumwandlung einer Zeitangabe into Sekunden seit 1970
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
-
hi ho
interessante information...
aber wo war denn nun deine frage? :-))
cua
n.d.p.
-
Hallo n.d.!
aber wo war denn nun deine frage? :-))
Ganz einfach: Es gab keine! Calo hat keine richtige Frage gestellt, sondern, so weit ich seinen Beitrag richtig verstanden habe, nur um die Meinung der Lesenden gebeten:
"Ich will mal nach Eurer Meinung zu einem Problem, das ich gerade habe, fragen."
Leider kann ich zu alledem nicht viel sagen ;-)
Bis danndann
PAF (patrickausfrankfurt)<img src="/selfaktuell/extras/selfcomm.jpg" alt=""> http://www.atomic-eggs.com/selfspezial/guests/advguest.cgi?view
<img src="http://www.atomic-eggs.com/selfspezial/atomicegg.gif" id="ei" alt="Atomic Eggs - die humosophische Seite" onMouseUp="window.location.href='http://www.atomic-eggs.com/'" onmouseover="if(document.all)document.all.ei.style.cursor='hand';status='http://www.atomic-eggs.com/';return true;" onmouseout="status='';return true;">
-
Moin moin!
interessante information...
aber wo war denn nun deine frage? :-))hehe *g* Hab eben mal laut gedacht, warum soll man denn auch immer was fragen? ;-) Aber ich wollte es eben doch mal zur Diskussion stellen, haette mich ja schliesslich auch irren koennen. Aber von mir aus koennen wir auch ueber Sinn und Unsinn der Sommerzeit diskutieren. Vielleicht weiss ja jemand ein paar Fakten zu dem Thema? http://www.sommerzeit.de/ ist irgendwie nicht so der Bringer. :-(
So long
-
-
Hallo Calocybe!
Das war wirklich mal ein interessanter Artikel, hat mich echt zum nachdenken gebracht! Ich frage mich wieso du die Zeitzone unbedingt einbeziehen willst. Du sagtest du bist dabei ein paar Statistiken über das Forumsarchiv zu erstellen. Die Zeitzone ist doch nur relevant, wenn du einen Zeitintervall auf die Stunde genau berechnen willst, also in Stunden angeben wie viel Zeit seit einem gewissen Eintrag vergangen ist. Für welche Art von statistischen Information musst du denn die Zeitspanne stundenenau berechnen? Wenn es nur um eine Formatierungssache geht, dann kannst du doch einfach das Datum irgendwie so ausgeben: 23.09.2000. Oder habe ich da etwas nicht kapiert?
Jedenfalls finde ich die Frage interessant, ob Module, die eine Zeitdifferenz berechnen wie z.B. datediff() in einigen Datenbanken die Zeitzonen wirklich berücksichtigt haben.
vielleicht wird ja sogar irgendwann die Sommerzeit wieder abgeschafft, was zu hoffen waere.
Warum denn? Für Programmierer kann das schon ein "pain in the ass" sein, aber schließlich macht man es aus Energiespargründen, was sinnvoll ist.
Gruß
Cruz-
Hi Cruz!
Die Zeitzone ist doch nur relevant, wenn du einen Zeitintervall auf die Stunde genau berechnen willst, also in Stunden angeben wie viel Zeit seit einem gewissen Eintrag vergangen ist.
Nun ja, ich bin eben ein Perfektionist, bei mir muss immer alles ganz genau sein. :-)
Für welche Art von statistischen Information musst du denn die Zeitspanne stundenenau berechnen? Wenn es nur um eine Formatierungssache geht, dann kannst du doch einfach das Datum irgendwie so ausgeben: 23.09.2000. Oder habe ich da etwas nicht kapiert?
Z.B. ist interessant, zu welchen Uhrzeiten am meisten gepostet wird. Also eine Kurve, die ueber 24 Stunden das mittlere Postingaufkommen angibt. Allerdings koennte man sich ueberlegen, ob man gerade dafuer diese Differenz doch nicht zurueckrechnet, da ja die Leute dann auch um eine Stunde versetzt aufstehen, leben und posten.
Jedenfalls finde ich die Frage interessant, ob Module, die eine Zeitdifferenz berechnen wie z.B. datediff() in einigen Datenbanken die Zeitzonen wirklich berücksichtigt haben.
Ich nehme an, intern werden die auf jeden Fall auch einfach die Anzahlen der Sekunden substrahieren. Also werden sie so eine Konvertierung machen muessen, die aus genannten Gruenden nicht 100% korrekt sein kann. Ist diesen Modulen auch nicht vorzuwerfen, wie ich finde, da man ja eigentlich davon ausgehen koennen sollte, dass zwei Zeiten aus derselben Zone verglichen werden.
vielleicht wird ja sogar irgendwann die Sommerzeit wieder abgeschafft, was zu hoffen waere.
Warum denn? Für Programmierer kann das schon ein "pain in the ass" sein, aber schließlich macht man es aus Energiespargründen, was sinnvoll ist.Wenn sich dadurch wirklich Energie sparen laesst, nehme ich einen Mehraufwand gerne in Kauf. (Wenn man von Anfang an dran denkt, gibt's da ja auch keine Probleme.) Doch soviel ich weiss gibt es diesen erhofften Spareffekt ueberhaupt nicht. Somit ist die Sommerzeit einfach ein gescheitertes Experiment (dass eben 20 Jahre gedauert hat; Sommerzeit gibt es in Dtl imho seit 1980). Die logische Folge ist fuer mich, sie wieder abzuschaffen.
So long
-
hallo,
Z.B. ist interessant, zu welchen Uhrzeiten am meisten gepostet wird. Also eine Kurve, die ueber 24 Stunden das mittlere Postingaufkommen angibt. Allerdings koennte man sich ueberlegen, ob man gerade dafuer diese Differenz doch nicht zurueckrechnet, da ja die Leute dann auch um eine Stunde versetzt aufstehen, leben und posten.
Wobei imho die Sommerzeit sowieso mitberücksichtigt werden sollte, da ja der Tagesablauf von der festgelegten und nicht der, na ja ich weiß nicht astronomischen vielleicht, Ughrzeit abhängt.
So lange die Zeiten immer innerhalb eines bestimmten Zeitrahmen Verwendung finden, ist eigentlich nicht relevant, wie die Zeiten gespeichert werden. O.k. es gibt gerade bei Sommer-Winterzeit-Umstellungen Probleme mit Zeiterfassungssystemen oder andere Systeme, welche eine homogene Zeitlinie benötigen.
Problematischer ist meienr Ansichtr nach vielmehr, wenn unterschiedliche Zeitzonen verwendet werden.
Leider habe ich bisher noch keine Möglichkeit gefunden, herauszubekommen, in welcher Zeitzone sich der Client gerade befindet, um so eine clientgerechte Uhrzeit darstellen zu können.Nehmen wir dieses Forum als Beispiel. Alles funktioniert wunderbar, solange der Client in Mitteleuropa ist. Sollte ich aber zufälligerweise gerade in den USA sein, und sehe mir mal die Postings an, dann sehe ich Uhrzeiten, welche mit der, in der ich aktuell bin, nichts mehr zu tun haben.
Das ist für dieses Formum vielleicht nicht so wichtig, in anderen Systemen, Ecommerce oder so, kann das imho zu Problemen führen.
Bei einem Mail wird, soweit ich weiß, die Zeit immer mit der Angabe der Zeitzone angegeben, was dazu führt, daß die Clients diese auch auswerten können und entsprechend der Clientzeitzone korrigieren können. So machts zumindest sendmail. Ob Exchange das auch macht, weiß ich nicht, da ich vor diesem Moloch bisher immer die Finger gelassen habe ;-)
Vielleicht kann sich daraus eine Frage für n.d.parker entwickeln. Ich versuchs mal:
weiß irgendwer eine Möglichkeit, serverseitig zu bestimmen, in welcher Zeitzone der Client gerade ist?Ansonsten kann ich nur sagen, daß ich sofern es möglich ist, die Zeitangaben immer in GMT speichere, um eine möglichst homogene Zeit zu realisieren.
Da fällt mir gerade ein, daß das auch zu Problemem führen kann. Wenn ich z.B. im Sommer die aktuelle Zeit abspeichere (19:44) dann speichere ich doch 17:44 GMT. Wenn ich dann im Winter darauf zugreife, dann stelle ich aber 18:44 dar. So ein Mist, wieder falsch. Hmm. Wir sollten doch auf Stardate umstellen, aber welche Berechnungsmethode sollen wir wählen die von TNG, den Filmen, oder doch von DS9 ?? Ich habs schon immer gesagt. Datum und Zeit ist nichts für Computer.
Grüße
Klaus-
Moin
Z.B. ist interessant, zu welchen Uhrzeiten am meisten gepostet wird. Also eine Kurve, die ueber 24 Stunden das mittlere Postingaufkommen angibt. Allerdings koennte man sich ueberlegen, ob man gerade dafuer diese Differenz doch nicht zurueckrechnet, da ja die Leute dann auch um eine Stunde versetzt aufstehen, leben und posten.
Wobei imho die Sommerzeit sowieso mitberücksichtigt werden sollte, da ja der Tagesablauf von der festgelegten und nicht der, na ja ich weiß nicht astronomischen vielleicht, Ughrzeit abhängt.
Ich glaube, wir meinen dasselbe. :-)
Problematischer ist meienr Ansichtr nach vielmehr, wenn unterschiedliche Zeitzonen verwendet werden.
Leider habe ich bisher noch keine Möglichkeit gefunden, herauszubekommen, in welcher Zeitzone sich der Client gerade befindet, um so eine clientgerechte Uhrzeit darstellen zu können.Waere mir auch neu, dass sowas geht. Alles was man hat, ist ja die IP-Adresse, und die ist nicht ortsgebunden.
Nehmen wir dieses Forum als Beispiel. Alles funktioniert wunderbar, solange der Client in Mitteleuropa ist. Sollte ich aber zufälligerweise gerade in den USA sein, und sehe mir mal die Postings an, dann sehe ich Uhrzeiten, welche mit der, in der ich aktuell bin, nichts mehr zu tun haben.
Yepp, und da gibt es auch einige Besucher hier, die das betrifft, soviel ich weiss. Aber immerhin werden die sicher wissen, wieviel sie draufaddieren muessen, wenn sie schon in einem dt.-sprachigen Forum lesen.
Fuer den SelfBrowser koennte man ja die Zeit in GMT uebertragen, die dann auf dem Client durch JS in die aktuelle Zeitzone uebersetzt wird.
Das ist für dieses Formum vielleicht nicht so wichtig, in anderen Systemen, Ecommerce oder so, kann das imho zu Problemen führen.
Ich nehme doch an, dass man in solchen eher kritischen Umgebungen nach professionelleren Loesungen sucht. *g*
Bei einem Mail wird, soweit ich weiß, die Zeit immer mit der Angabe der Zeitzone angegeben, was dazu führt, daß die Clients diese auch auswerten können und entsprechend der Clientzeitzone korrigieren können. So machts zumindest sendmail. Ob Exchange das auch macht, weiß ich nicht, da ich vor diesem Moloch bisher immer die Finger gelassen habe ;-)
Sendmail? Bei mir macht das Netscape persoenlich. D.h. der original Date-Header wird nicht veraendert, erst in der Darstellung wird die Zeit angepasst. Das kann meines Wissens sogar Outlook, und wenn es dort schon geht ... ;-)
Vielleicht kann sich daraus eine Frage für n.d.parker entwickeln. Ich versuchs mal:
weiß irgendwer eine Möglichkeit, serverseitig zu bestimmen, in welcher Zeitzone der Client gerade ist?Wie gesagt, ich denke, das ist technisch nicht moeglich.
Ansonsten kann ich nur sagen, daß ich sofern es möglich ist, die Zeitangaben immer in GMT speichere, um eine möglichst homogene Zeit zu realisieren.
Mach ich auch schon immer so.
Da fällt mir gerade ein, daß das auch zu Problemem führen kann. Wenn ich z.B. im Sommer die aktuelle Zeit abspeichere (19:44) dann speichere ich doch 17:44 GMT. Wenn ich dann im Winter darauf zugreife, dann stelle ich aber 18:44 dar. So ein Mist, wieder falsch. Hmm. Wir sollten doch auf Stardate umstellen, aber welche Berechnungsmethode sollen wir wählen die von TNG, den Filmen, oder doch von DS9 ?? Ich habs schon immer gesagt. Datum und Zeit ist nichts für Computer.
Schau mal Deine Mails einmal vor und einmal nach der Umstellung Sommer-/Winterzeit an. Ploetzlich sind die Zeiten der Mails auf einmal alle um 1 Stunde verschoben.
Ja, eine globale universelle Zeit waere schoen. Dann geht eben in manchen Laendern die Sonne erst 20:00 auf, was soll's? Gibt's ja auch (UTC), nur bring das mal den Leuten bei... :-(
So long
-
Moin
'nAbend,
weiß irgendwer eine Möglichkeit, serverseitig zu bestimmen, in welcher Zeitzone der Client gerade ist?
Wie gesagt, ich denke, das ist technisch nicht moeglich.
Technisch wärs möglich, wenn im HTTP-Request die Zeitzone mit eingetragen würde, z.B.
Local-Timezone: +0200
oder
Local-Timezone: MESTAber da müßte halt der Browser mitmachen, beim SelfBrowser wäre das ja möglich, aber die anderen. Na ich weiß nicht.
Schau mal Deine Mails einmal vor und einmal nach der Umstellung Sommer-/Winterzeit an. Ploetzlich sind die Zeiten der Mails auf einmal alle um 1 Stunde verschoben.
also doch wieder GMT und umrechnen ;-)
Ja, eine globale universelle Zeit waere schoen. Dann geht eben in manchen Laendern die Sonne erst 20:00 auf, was soll's? Gibt's ja auch (UTC), nur bring das mal den Leuten bei... :-(
Es gibt Leute, für die geht auch jetzt erst um 20:00 die Sonne auf ;-)
Grüße
Klaus
-
-
-
hi!
Sommerzeit gibt es in Dtl imho seit 1980
Mein Spezialgebiet: die Sommerzeit wurde wieder eingeführt am
6. April 1980, wo die Uhr um 2:00 Uhr auf 3:00 Uhr vorgestellt wurde.:)
bye, Frank!
-
-
-
Hi,
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.)
Wenn Du das gesamte Forums-Archiv sequentiell (geordnet nach Posting-Nummern) verarbeitest, findest Du die Sprungstelle, an denen die Uhr zurückgestellt wurde (sofern in beiden Stunden "zwischen 2 und 3 Uhr" mindestens ein Posting erfolgte - wenn nicht, dann hast Du dort eine Unschärfe, aber wenigstens kein Sortierproblem).
mfG - Michael
-
Hi!
Wenn Du das gesamte Forums-Archiv sequentiell (geordnet nach Posting-Nummern) verarbeitest, findest Du die Sprungstelle, an denen die Uhr zurückgestellt wurde (sofern in beiden Stunden "zwischen 2 und 3 Uhr" mindestens ein Posting erfolgte
... UND die Uhrzeit des zweiten Postings numerisch kleiner als die des ersten ist. D.h. wurde das erste um 2:33 MESZ und das zweite um 2:15 MEZ abgeschickt, ist offensichtlich, dass die Umstellung zwischendrin erfolgte. Wurde aber das erste um 2:15 MESZ und das zweite um 2:33 MEZ abgeschickt, ist nicht sicher, ob beide Postings in derselben Stunde gemacht wurden (und wenn ja, in welcher), oder in unterschiedlichen.
Vom Prinzip her ist die Idee aber gut, vielleicht hilft sie ja mal. Leider werden um diese Uhrzeit eher weniger Postings gemacht.
So long
-
Hi auch,
Leider werden um diese Uhrzeit eher weniger Postings gemacht.
... was man durch automatisches Erzeugen eines Postings (LWP::Simple, Skript via crontab zum Umschaltzeitpunkt zwischen Sommer- und Winterzeit starten) "beheben" könnte. ;-)
mfG - Michael
-
-