+ (ASP/PHP) Zeitzone eines Nutzers ermitteln

[Gernot Back]

Hallo an alle,

ich arbeite ja im Moment für ein Internetportal, das sich gerade internationalisiert. Die registrierten Nutzer aus aller Welt können über dieses Portal auch miteinander kommunizieren und Nachrichten versenden.

Nun ist es im Moment so, dass alle Nachrichten mit einer Zeitstempel-Signatur versehen werden, die -je nachdem- der Mitteleuropäischen Sommer- oder Winterzeit entspricht (Die meisten Nutzer des Portals, ich schätze mal so 95% kommen halt immer noch aus dieser Zeitzone).

Jetzt möchten wir aber, dass jedem Nutzer die Zeit entsprechend der in seiner Systemzeit eingestellten Zeitzone als Absendezeitpunkt einer Nachricht angezeigt wird.

Mit der Javascript-Methode Date.getTimezoneOffset() kann ich die clientseitig eingestellte Zeitverschiebung gegenüber der UTC-Zeit ermitteln, die unabhängig von Sommer- und Winterzeit bezogen auf den Greenwich-Meridian immer weiter läuft. Aber in vielen Ländern gibt es Sommer- und Winterzeit, und die Umstellungstermine sind beileibe nicht überall dieselben. In einigen Ländern gibt es sogar eine Winter-, eine Sommer- und eine Hochsommerzeit, in welch letzterer die Uhr sogar um zwei Stunden gegenüber der Standard(winter)zeit verstellt wird.

Kann ich aus der Differenz einer serverseitig ausgelesenen UTC-Zeit und einer clientseitig ausgelesenen Systemzeit eindeutig auf die im System eingestellte Zeitzone eines Nutzers schließen? Was, wenn sich jemand in einem Land in Äquatornähe (also ohne spezielle von der Standardzeit abweichende Sommerzeit) während unseres Sommers bei unserer Datenbank  registriert? Bekommt der dann in unserem Winter einen um eine Stunde verschobenen Zeitstempel auf seine Nachrichten, der seiner Ortszeit nicht mehr entspricht?

Vor einem Jahr hatten Raik und Ingo einen längeren Thread über das Problem, aber ich werde nicht so recht schlau, ob sie wirklich das Ei des Kolumbus dabei gefunden haben.

http://forum.de.selfhtml.org/archiv/2004/10/t93166/

Gibt es möglicherweise Dienste im WWW, die einem zeitnah mitteilen, wenn sich an der Zeitzonenzugehörigkeit/Umstellungsterminen von Winter- auf Sommerzeit und umgekehrt in einem Land aufgrund von Gesetzesänderungen etwas ändert, ja den Zeitunterschied zu UTC dann sogar automatisch neu berechnen?

Gruß Gernot

[Manuel B.]

Nur mal so ein Gedanke:
Warum lässt du den Benutzer beim Registrieren nicht seine Zeitzone auswählen?
Genauso, wie die Spracherkennung per Browser problematisch sein kann, ist es mit der Zeitzone genauso.

Generell liegt es immer am User, ob er die richtige Zeit bekommt, wenn du dir per offSet berechnest.

[Gernot Back]

Hallo Manuel,

Nur mal so ein Gedanke:
Warum lässt du den Benutzer beim Registrieren nicht seine Zeitzone auswählen?

Ja, das haben wir auch vor, wir wollen es den Nutzern nur so mundgerecht wie möglich machen und den selectedIndex der Timezone-Auswahlbox schon entsprechend seiner Systemzeiteinstellungen vorbelegen.

Du kennst doch die User von heute, die sind so ungeduldig, dass viele ohne groß weiter zu prüfen einfach nur durchklicken, und da soll es halt trotzdem in den meisten Fällen passen.

Gruß Gernot

[Da Pinky]

also am besten wäre es wenn der nutzer seine zeitzone selbst einstellt und du diese in seinem profil in der db mit speicherst.

vor ort gibts manchmal ziehmliche unterschiede die deine php-zeitfunktion eventuell nicht kennt. war mal eine ganze zeit in australien, da isses ganz besonders schlimm: 3 zeitzonen, unterschied zur nächsten manchmal 30 min oder 1.5h, in einem staat kommt noch sommer/winterzeit hinzu, in den anderen nicht. ist aber auch egal, abseits der grossen städte geht "4pm" von 3.01pm bis 5pm...

[Gernot Back]

Hallo nochmal,

Gibt es möglicherweise Dienste im WWW, die einem zeitnah mitteilen, wenn sich an der Zeitzonenzugehörigkeit/Umstellungsterminen von Winter- auf Sommerzeit und umgekehrt in einem Land aufgrund von Gesetzesänderungen etwas ändert, ja den Zeitunterschied zu UTC dann sogar automatisch neu berechnen?

Diese Dienste scheint es tatsächlich zu geben.

Da habe ich selbst jetzt gerade einen interessanten Link zu gefunden. Allerdings bin ich selbst noch ratlos, was und wie ich es verwerten soll:

http://www.twinsun.com/tz/tz-link.htm

Gruß Gernot

[karl]

Hallo Gernot

Ich schlage folgenden Lösungsansatz vor.
Eine serverseitige Zeit ist dabei gar nicht erforderlich.
Im gegenteil, sie würde, wenn der Client eine falsch eingestellte Uhr hat, Fehler verursachen.
Da dieser Ansatz nur auf Clientzeiten basiert müsste er auch stimmen wenn die Uhr des Client nicht ganz richtig eingestellt ist.

ermittle client-utc (getUTCHours() und getUTCMinutes()
ermittle client-utc-offset (getTimezoneOffset())
ermittle client-zeit (getTime())

Zur Winnterzeit müsste gelten:
client-zeit = client-utc + client-utc-offset

Zur Sommerzeit stimmt diese Formel nicht und daraus
berechne den sommerzeit bedingten offset des client:
client-sommerzeit-offset = client-zeit - (client-utc + client-utc-offset)

Aus diesem client-sommerzeit-offset kannst du nun ermittel ob er Sommerzeit hat:
client-sommerzeit-offset ca. 0 bedeutet Winterzeit
client-sommerzeit-offset ca. 60 min bedeutet Sommerzeit
......
......

Das ist nur der Denkansatz. Die Umsetzung insbesonder im Zeitraum um Mitternacht ist sicher etwas aufwendiger.

l.g. karl

[Gernot Back]

Hallo karl,

vielen Dank für deinen Denkansatz, aber ich habe Zweifel, dass er funktionieren würde, denn es macht ja keinen Unterschied, ob ich mir den TimezoneOffset über die entsprechende Methode des Date-Objekts ausgeben lasse oder aus der Differenz zwischen Systemzeit und UTC-Systemzeit selbst berechne:

  
var sysTime = new Date();  
var meld = "TimezoneOffset: " + sysTime.getTimezoneOffset();  
meld += "\nTagesminuten: " + sysTime.getHours()*60 + sysTime.getMinutes();  
meld += "\nUTCTagesminuten: " + sysTime.getUTCHours()*60 + sysTime.getUTCMinutes();  
meld += "\nselbst errechnete\nDifferenz: " + ((sysTime.getUTCHours()*60 + sysTime.getUTCMinutes()) - (sysTime.getHours()*60 + sysTime.getMinutes()));  
alert(meld);  

Da kann ich meine Systemuhr auch einen Monat und damit auf die Mitteleuropäische Sommerzeit im Oktober zurückstellen; da kommt dann halt ein TimezoneOffset von 120 statt 60 Minuten heraus, egal nach welcher Berechnungsmethode.

Oder habe ich deinen Gedankengang gar nicht richtig verstanden?

Ich denke, wir kommen auch gar nicht um eine Datenbank herum, in der die Regeln für die Umstellung von Sommer- auf Winterzeit stehen. Hinzu kommt folgendes Problem: Wir haben ja sieben Monate Sommer- und nur fünf Monate Winterzeit. (Die Umstellung von Sommer- auf Winterzeit erfolgt einen Monat nach dem Äquinoktium) Deshalb dürften die Termine für die Umstellung auf der Südhalbkugel auch um jeweils einen Monat differieren. Die stellen dann wahrscheinlich Ende Mai und Ende September um, während wir das ja Ende April und Ende Oktober machen. Wir können also auch nicht einfach Pi mal Daumen unsere Umstellungstermine an unserem Serverstandort zum Maßstab machen.

Die Zeitzone soll auch nicht jedesmal, bei jedem Nachrichtenversand neu ermittelt werden, sondern nur einmalig bei Registrierung in unserere Datenbank gespeichert werden und dann bei Umzug des Nutzers in eine andere Zeitzone ggf. in den Nutzereinstellungen geändert werden können. Eine manuelle Umstellung beim Wechsel von Sommer- auf Winterzeit und umgekehrt fände ich eine Zumutung.

Gruß Gernot

[Gernot Back]

Hallo nochmal,

...während wir das ja Ende April und Ende Oktober machen.

Ups! Natürlich Ende März und Ende Oktober!

Gruß Gernot

[Ingo Turski]

Hi,

Die Zeitzone soll auch nicht jedesmal, bei jedem Nachrichtenversand neu ermittelt werden, sondern nur einmalig bei Registrierung in unserere Datenbank gespeichert werden und dann bei Umzug des Nutzers in eine andere Zeitzone ggf. in den Nutzereinstellungen geändert werden können.

Es ist doch garnicht erforderlich, die Zeitzone automatisch zu ermitteln, um die Abweichung von der Serverzeit herauszubekommen und die Zeiten passend auszugeben. Vergleiche doch einfach die Clientzeit mit der Serverzeit und runde auf 1/4 Stunde, dann hast Du die Differenz (wenn die Uhr des Client mehr als 1/4 Stunde falsch geht, hat er halt Pech gehabt ;-)
Diese Zeitabweichung ermittelst und berücksichtigst Du bei jedem Login - solange, bis der User sich bequemt, seine Zeitzone manuell in die Datenbank einzutragen.

freundliche Grüße
Ingo

[Gernot Back]

Hallo Ingo,

Vergleiche doch einfach die Clientzeit mit der Serverzeit und runde auf 1/4 Stunde, dann hast Du die Differenz (wenn die Uhr des Client mehr als 1/4 Stunde falsch geht, hat er halt Pech gehabt ;-)

Dein Ansatz wäre ja durchaus brauchbar, wenn wir für unsere Bestandskunden nicht bereits ein Auto-Login über Cookie eingerichtet hätten. Wir würden dann sogar auf eine halbe Stunde runden, weil wir auf die Nutzer aus der Zeitzone Katmandu, die tatsächlich eine ganz krumme Verschiebung von 5 3/4 Stunden gegenüber unserer Serverzeit hat, verzichten würden. Da haben wir bisher ohnehin keinen Nutzer.

Wir werden jetzt erst einmal alles auf unsere Winterserverzeit beziehen und hoffen, dass wir es bis zur Sommerzeitumstellung im nächsten Frühjahr auch mit einer Anbindung an die unter diesem Link genannte Datenbank hinbekommen:

http://www.twinsun.com/tz/tz-link.htm

Das Problem ist nur, dass wir mit ASP und Windows und nicht mit Linux-Servern arbeiten, aber selbst das scheint ja irgendwie machbar zu sein, denn auf der oben verlinkten Seite finden sich ja auch wiederum Links zu Seiten, die das mit ASP realisieren. Die Frage ist nur wie...

Gruß Gernot

[Ingo Turski]

Hi,

Vergleiche doch einfach die Clientzeit mit der Serverzeit und runde auf 1/4 Stunde, dann hast Du die Differenz (wenn die Uhr des Client mehr als 1/4 Stunde falsch geht, hat er halt Pech gehabt ;-)

Dein Ansatz wäre ja durchaus brauchbar, wenn wir für unsere Bestandskunden nicht bereits ein Auto-Login über Cookie eingerichtet hätten.

Wo siehst Du da ein Problem? Wenn die Zeitzone dieser Kunden bekannt ist, wird diese genommen, und wenn nicht, eben die Differenz ermittelt. Die Kunden könnten dann gebeten werden, ihre Zeitzone nachzutragen.

Wir würden dann sogar auf eine halbe Stunde runden, weil wir auf die Nutzer aus der Zeitzone Katmandu, die tatsächlich eine ganz krumme Verschiebung von 5 3/4 Stunden gegenüber unserer Serverzeit hat, verzichten würden.

Ich meinte auf 1/4 Stunde runden wegen Zeitzonen mit x 1/2 Stunden Unterschied. Davon gibt's mehrere.

freundliche Grüße
Ingo

[karl]

Hallo Gernot

Da kann ich meine Systemuhr auch einen Monat und damit auf die Mitteleuropäische Sommerzeit im Oktober zurückstellen; da kommt dann halt ein TimezoneOffset von 120 statt 60 Minuten heraus, egal nach welcher Berechnungsmethode.

Oder habe ich deinen Gedankengang gar nicht richtig verstanden?

Du hast mich schon richtig verstanden.
Mein Fehler war dass ich angenommen hatte getTimezoneOffset() würde den reinen "Winterzeit-Offset" liefern. Tuts aber nicht sondern berücksichtigt auch die Sommerzeit und damit kann so nicht gehen.

Ich denke, wir kommen auch gar nicht um eine Datenbank herum,

Sieht wohl so aus.
Wenn du Infos zu den Zeitumstellungen suchst hätte ich einen Link für dich. http://www.weltzeituhr.com/laender/welt.shtml

l.g. karl :-)´