Hey ho.
Der Server rechnet immer in UTC, genau wie Javascript. Entsprechend nutzt man Date.setTime() und z.B. Date.toLocaleString() zur Anzeige. Für den Rückweg greift man auf die lokale Zeit im Date-Objekt zu (Date-Methoden ohne UTC im Namen) und übermittelt den Wert von Date.getTime().
Das ist interessant für mich. Hätte auch den Vorteil, dass es für bereits registrierte Nutzer funktioniert. Da die Anwenderschaft in Deutschland und Australien arbeitet, würde ich die UTC auch noch reinnehmen und in den Nutzereinstellungen "UTC" oder "OS time" in einem select anbieten und als default "OS time" nehmen.
Habs jetzt noch nicht probiert, aber ich denke, ich schaffe es. Ich hätte jetzt erstmal vermutet, dass ich für einen beliebigen timestamp ersteinmal die Differenz zwischen aktuellem Timestamp auf Server- und Klientseite brauche und diesen Offset dann mit dem beliebigen Timestamp verrechne. Aber ich nehme an, die Date. functions machen das bereits. Werde es morgen mal versuchen.
Ein weiteres Problem ist eine nur tagesgenaue Zeitangabe. Hier empfiehlt es sich, als Zeitpunkt 12:00 mittags (UTC) einzugeben, je nach geografischer Verteilung vielleicht auch zwei bis drei Stunden früher oder später. Stellt nimmt man nämlich Mitternacht UTC für eine Datumsangabe ein, zeigen Systeme westlich von Greenwich einen anderen Tag an als Systeme östlich von Greenwich.
Leuchtet ein, aber es handelt sich immer um volle Uhrzeiten.
Vielen Dank für diesen guten Praxistipp.
Alternative hatte ich zwischenzeitlich noch daran gedacht, die geolocation (mittels IP) für die php-Zeitzonenbeschreibung heranzuziehen. In der Form, dass die Ewig lange liste an Einträgen schonmal den wahrscheinlichsten Eintrag vorselektiert... Aber ich habe gehört, dass die Geolocations mitunter arg daneben liegen und außerdem brauche ich dann noch eine DB. Ist mir eigentlich zuviel Arbeit. Ich denke ich gehe mit der Javascriptmethode.
Thanks,
Alexander
Cheers,
Baba