nicht angemeldet
Hallo, Ingo!
ich hab nochmal darüber nachgedacht und bin mir jetzt ziemlich sicher, dass ich richtig liege mit meinen überlegungen.
ich weiß es nicht genau, aber vielleicht geht das doch viel simpler. der Timestamp (in Javascript zumindest) gibt doch die abgelaufenen Millisekunden seit dem 1.1.70 (?) aus. Erst das Date-Obhekt macht daraus ein Datum und eine Zeit.
... die ich benötige, um auf dem client-rechner evtl. bestehende differenzen (sommerzeit) in der zeitverschiebung (zeitzonen) zu gmt/utc festzustellen.
und weil ich mit javascript aus einem timestamp kein datum mehr erzeugen kann, übergebe ich die durch umwandlung auf gmt/utc verschiebungsbereinigte endzeit der auktionen an javascript, errechne daraus die lokale zeit, deren offset und timestamp und vergleiche diesen mit dem offset der lokalen zeit auf dem clienten.
weil getTimezoneOffset() die sommerzeit als zeitzonenverschiebung interpretiert, erhalte ich sonst, um die sommerzeit verschobene, falsche rechenergebnisse.
Wenn nun dieser Timestamp in PHP und Javascript derselbe wäre
ja, ist er.
und der Startzeitpunkt in jeder Zeitzone ebenfalls, dann ...
solange die momentane zeit und die endzeit beide in der sommerzeit, oder der winterzeit liegen, gibt es keine probleme. liegt aber eine in der sommerzeit und die andere in der winterzeit, vergleiche ich sozusagen auf basis unterschiedlicher zeitzonen oder anders gesagt: mit unterschiedlicher rechenbasis (was logischer weise nicht gut gehen kann).
für die zeit, die in der sommerzeit liegt, kommt ein falscher timestamp heraus. der ist dann um die sommerzeit nach "vorn" oder nach "hinten" verschoben.
freundl. Grüsse aus Berlin, Raik