Raik: / PHP Verwirrung mit Zeitrechnung

Hallo!

ich will die tage/stunden/minuten/sekunden bis zu einem gegebenen zeitpunkt in der zukunft mit javascript auf einer mit php erzeugten seite herunterzählen lassen.
dabei ist mir aufgefallen, dass der javascript-zähler eine stunde zu viel anzeigt, solange die restzeit noch über einen tag ist. erst in den letzten 24 std stimmt die anzeige.
ich würde das ganze gern so schreiben, dass auch bei aufruf der seite z.b. in amerika die rechnung noch stimmt, die zeitverschiebung also berücksichtigt wird.
im moment bin ich etwas durcheinander, was die zusammenhänge angeht. geht meine uhr jetzt falsch, weil javascript die sommerzeit nicht berücksichtigt, oder weil der von php erzeugte timestamp evtl. die zeitverschiebung zu gmt nicht berücksichtigt?

das javascript an sich funktioniert so weit.

<script type="text/javascript">
<!--
//ich übergebe mit php den timestamp
var Start = 1099342194;

function toSt(n) {
s = ""
if (n < 10) s += "0"
return s + n.toString();
}

function go() {
d = new Date();
count = Math.floor(Start - (d.getTime()/1000));

if (count <= 0) {
document.clock.time.value = "Abgelaufen";
return;
}

var secs = toSt(count % 60);
count = Math.floor(count / 60);
var mins = toSt(count % 60);
count = Math.floor(count / 60);
var hours = toSt(count % 24);
count = Math.floor(count / 24);
var days = count;
document.clock.time.value = days + "T " + hours + ":" + mins + ":" + secs;
}
// -->
</script>

wer kann mir etwas auf die sprünge helfen, wie das zu lösen ist? welche zeitverschiebungen sind jetzt wo (server/client) zu berücksichtigen und ist das überhaupt für verschiedene zeitzonen machbar?

freundl. Grüsse aus Berlin, Raik

  1. Hello,

    hast Du auch an die Sommerzeitumstellung am letzten Wochenende im Oktober gedacht?

    Harzliche Grüße aus http://www.annerschbarrich.de

    Tom

    --
    Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
    Nur selber lernen macht schlau
    1. Hallo, Tom!

      hast Du auch an die Sommerzeitumstellung am letzten Wochenende im Oktober gedacht?

      geht meine uhr jetzt falsch, weil javascript die sommerzeit nicht berücksichtigt, oder ...

      ^^^^^^^^^^
      ja, daran gedacht habe ich. nur weis ich eben nicht, ob mein countdown deswegen oder wegen der zeitverschiebung zu gmt falsch geht.
      ich glaube, es wäre gut, sich sowohl mit php, als auch mit javascript nach gmt zu richten als einheitliche basis, damit die restzeit auch auf einem amerikanischen rechner richtig berechnet wird.
      aber mir ist nicht klar, ob hier php oder javascript diese eigenartige abweichung verursacht.
      wie gesagt, ist die verbleibende zeit unter einem tag, stimmt die anzeige. darüber wird eine stunde zu viel angezeigt.

      freundl. Grüsse aus Berlin, Raik

      1. Hi,

        ich glaube, es wäre gut, sich sowohl mit php, als auch mit javascript nach gmt zu richten als einheitliche basis, damit die restzeit auch auf einem amerikanischen rechner richtig berechnet wird.

        eher UTC, da Dir Javascript dieses bereitstellt. Natürlich müßtest Du die Zeitangaben dann auch als UTC kennzeichnen.
        Allerdings berücksichtigt UTC die Sommerzeit eben gerade nicht, so daß in diesem Fall die zusätzliche - doppelte - Stunde fehlt. Jetzt ist die Frage, ob Du die tatsächlich ablaufenen Stunden zählen willst oder die rechnerische Differenz der angegebenen Daten.

        freundliche Grüße
        Ingo

        1. Hallo, Ingo!

          Jetzt ist die Frage, ob Du die tatsächlich ablaufenen Stunden zählen willst oder die rechnerische Differenz der angegebenen Daten.

          die differenz. aber das kuriose ist ja, dass diese zusätzliche stunde in den letzten 24 stunden vor ablauf verschwindet.

          freundl. Grüsse aus Berlin, Raik

          1. Hi,

            die differenz. aber das kuriose ist ja, dass diese zusätzliche stunde in den letzten 24 stunden vor ablauf verschwindet.

            nein. genau genommen noch einige Sunden früher und kurios ist das garnicht.

            alert( (new Date(2004,9,31,4) - new Date(2004,9,31,2))/3600000 );
            ergibt 2 Stunden Differenz zwischen 2 und 4 Uhr, während
            alert( (new Date(2004,9,31,4) - new Date(2004,9,31,1))/3600000 );
            die tatsächlich doppelt _ablaufende_ Stunde zwischen 1 und 4 Uhr mitzählt und auf 4 kommt.

            Daher die Frage nochmal: was willst Du genau zählen? ;-)

            freundliche Grüße
            Ingo

            1. Hallo, Ingo!

              Daher die Frage nochmal: was willst Du genau zählen? ;-)

              konkret die verbleibende zeit bis zum ende einer ebay-auktion.

              freundl. Grüsse aus Berlin, Raik

              1. Hi,

                konkret die verbleibende zeit bis zum ende einer ebay-auktion.

                dann ist die zusätzliche Stunde gerechtfertigt, da sie tatsächlich abläuft.
                new Date() liefert am 31.10.04 beim ersten Erreichen von 2 Uhr die Zeit 02:00:00 UTC +02:00 umd nach der Umschaltung 02:00:00 UTC +01:00, also erkennbar. Wenn Du auch während der Zeitumschaltung korrekte Werte ausgeben willst, müßtest Du das evtl. noch abfragen. Dabei habe ich mir aber noch nicht überlegt, wie das Ganze dann in anderen Zeitzonen aussieht...

                freundliche Grüße
                Ingo

                1. Hallo, Ingo!

                  dann ist die zusätzliche Stunde gerechtfertigt, da sie tatsächlich abläuft.
                  new Date() liefert am 31.10.04 beim ersten Erreichen von 2 Uhr die Zeit 02:00:00 UTC +02:00 umd nach der Umschaltung 02:00:00 UTC +01:00, also erkennbar. Wenn Du auch während der Zeitumschaltung korrekte Werte ausgeben willst, müßtest Du das evtl. noch abfragen. Dabei habe ich mir aber noch nicht überlegt, wie das Ganze dann in anderen Zeitzonen aussieht...

                  tut mir leid, nach etlichen versuchen bin ich immer noch nicht schlauer. :-(
                  ich dachte, dass ich die von ebay angegebenen zeiten auf GMT/UTC umrechnen muss. allerdings hat ein datum, das ich auf GTM umrechne, danach immer noch den gleichen timestamp.
                  heist das jetzt, alle (php-)timestamps beziehen sich immer auf GMT/UTC?

                  und wenn ich mit javascript die zeit auf dem clienten und daraus den timestamp errechne, worauf bezieht der sich dann? auch auf GMT/UTC?
                  dann müsste ich nur ermitteln, welche abweichung evtl. noch durch die lokale sommerzeit des clienten entsteht. ich hab zwar gelesen, dass diese sommerzeitumschaltung überall auf der welt zu unterschiedlichen zeiten erfolgt, aber ob immer nur eine stunde verschiebung erfolgt, oder wie 1947 von zwei stunden ("Hochsommerzeit"), das konnte ich nicht herausfinden.
                  nur: wie bekomme ich mit javascript heraus, ob die zeitverschiebung komplett durch die zeitzone verursacht wird, oder zusätzlich gerade durch die sommerzeit?
                  da die zeiträume der umstellung sich ja auf dem server und clienten unterscheiden können, kann ich nur GMT/UTC als rechenbasis nehmen.

                  freundl. Grüsse aus Berlin, Raik

                  1. Hi,

                    heist das jetzt, alle (php-)timestamps beziehen sich immer auf GMT/UTC?

                    eigentlich schon. Nur die Ausgabe muß man genau betrachten. In Javascript wird aktuell Sun Oct 31 01:35:00 UTC+0200 2004 ausgegeben. Die zusätzlich angegebenen 2 Stunden wieder abgezogen, hast Du UTC.
                    Eine Stunde später wirst Du Sun Oct 31 02:35:00 UTC+0200 erhalten und noch eine Stunde später Sun Oct 31 02:35:00 UTC+0100. new Date(2004,9,31,2,35) liefert allerdings bereits jetzt Winterzeit: Sun Oct 31 02:35:00 UTC+0100 2004.

                    nur: wie bekomme ich mit javascript heraus, ob die zeitverschiebung komplett durch die zeitzone verursacht wird, oder zusätzlich gerade durch die sommerzeit?

                    da hatte ich ja auch länger dran gebastelt und dank einiger Tips hier (insbesondere dem Hinweis auf mögliche halbstündige Abweichungen von der UTC) auch hoffentlich zeitzonenübergreifend hinbekommen; zu sehen in meiner Berechnung der Kalenderwoche. Unklar ist mit nur noch, welches Referenzdatum ich wählen kann, um die reine Zeitzonenabweichung ohne Sommerzeit herauszubekommen. Ich nehme jetzt den 1. Januar, an dem aber vielleicht irgendwo in der südlichen Hemisphäre doch Sommerzeit herrscht.

                    freundliche Grüße
                    Ingo

                    1. Hallo, Ingo!

                      heist das jetzt, alle (php-)timestamps beziehen sich immer auf GMT/UTC?
                      eigentlich schon. Nur die Ausgabe muß man genau betrachten. In Javascript wird aktuell Sun Oct 31 01:35:00 UTC+0200 2004 ausgegeben. Die zusätzlich angegebenen 2 Stunden wieder abgezogen, hast Du UTC.
                      Eine Stunde später wirst Du Sun Oct 31 02:35:00 UTC+0200 erhalten und noch eine Stunde später Sun Oct 31 02:35:00 UTC+0100. new Date(2004,9,31,2,35) liefert allerdings bereits jetzt Winterzeit: Sun Oct 31 02:35:00 UTC+0100 2004.

                      soweit klar jetzt.

                      nur: wie bekomme ich mit javascript heraus, ob die zeitverschiebung komplett durch die zeitzone verursacht wird, oder zusätzlich gerade durch die sommerzeit?
                      da hatte ich ja auch länger dran gebastelt und dank einiger Tips hier (insbesondere dem Hinweis auf mögliche halbstündige Abweichungen von der UTC) ...

                      halbstündlich?!? sowas gibts auch noch?!? neeeiiiinnnnnnnnn!!! (frei nach homer simpson)

                      Unklar ist mit nur noch, welches Referenzdatum ich wählen kann, um die reine Zeitzonenabweichung ohne Sommerzeit herauszubekommen. Ich nehme jetzt den 1. Januar, an dem aber vielleicht irgendwo in der südlichen Hemisphäre doch Sommerzeit herrscht.

                      ja, mit sicherheit gibts sowas.

                      ich gehe im moment folgenden (steinigen) weg:

                      • die lokale auktions-endzeit auf dem server auf gmt/utc umrechnen und in die seite schreiben
                      • clientseitig einem neuen datumsobjekt diese daten (jahr, ... , sekunden) mit "setUTC***()" zuweisen
                      • das datum dann mit "toLocaleString()" in die clientzeit umrechnen und mit "getTimezoneOffset()" das offset zu gmt/utc ermitteln
                      • ebenso das offset der aktuellen zeit ermitteln
                      • die differenz beider ermitteln, um sommerzeitverschiebungen zwischen beiden ausgleichen zu können (damit der countdown richtig zählt)
                      • mit "getTime()/1000" die timestamps beider ermitteln
                      • aus der differenz der beiden und der ermittelten sommerzeitdifferenz die noch verbleibenden sekunden ermitteln
                      • und mit modulo (%) die rest -sekunden, -stunden, -minuten und -tage ausrechnen und anzeigen

                      ich hoffe, das ist soweit die richtige vorgehensweise und nicht unnötig kompliziert.

                      freundl. Grüsse aus Berlin, Raik

                      1. Hi,

                        ich hoffe, das ist soweit die richtige vorgehensweise und nicht unnötig kompliziert.

                        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. Wenn nun dieser Timestamp in PHP und Javascript derselbe wäre und der Startzeitpunkt in jeder Zeitzone ebenfalls, dann ...

                        freundliche Grüße
                        Ingo

                        1. 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

                          1. Hi,

                            und weil ich mit javascript aus einem timestamp kein datum mehr erzeugen kann

                            wieso?
                            var timestamp = 1099272882359; var zeit=new Date(); zeit.setTime(timestamp);

                            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.

                            bist Du Dir da sicher? Der timestamp ist doch lediglich die Zahl der verstrichenden Millisekunden. Erst die Date-Funktion macht daraus eine Sommer- oder Winterzeit.

                            freundliche Grüße
                            Ingo

                            1. Hallo, Ingo!

                              var timestamp = 1099272882359; var zeit=new Date(); zeit.setTime(timestamp);

                              vielen dank! ich hab die seite immer wieder rauf und runter gelesen, aber auf die idee bin ich nicht gekommen. das vereinfacht den code erheblich.

                              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.
                              bist Du Dir da sicher? Der timestamp ist doch lediglich die Zahl der verstrichenden Millisekunden. Erst die Date-Funktion macht daraus eine Sommer- oder Winterzeit.

                              nein, inzwischen bin ich mir wieder über garnichts mehr sicher. :-(
                              ------------------------------
                                  <script type="text/javascript">
                                  <!--
                               var GMTdates = new Array();
                               function offset_korrektur(timestamp,Nr){
                                      var dat = new Date();
                                      dat.setTime(timestamp);
                                      var stamp = timestamp/1000;
                                      var offset = dat.getTimezoneOffset()*60;
                                      GMTdates[Nr] = stamp + offset;
                               }
                                  // -->
                                  </script>
                              ------------------------------
                                        <SCRIPT type=text/javascript>
                                        document.write("<input class=timer value='' readonly name='time1'>");
                                        offset_korrektur(1099258293000,1);  //timestamp in millisekunden und laufende nummer
                                        </SCRIPT>

                              <SCRIPT type=text/javascript>
                                        document.write("<input class=timer value='' readonly name='time2'>");
                                        offset_korrektur(1099342194000,2);
                                        </SCRIPT>

                              ............... u.s.w.

                              ------------------------------
                                  <script type="text/javascript">
                                  <!--
                                  function go(){
                                  var datum = new Date();
                                  var offset = datum.getTimezoneOffset()*60;
                                  var timestamp = Math.floor((datum.getTime()/1000) + offset);

                              for (i=1;i<GMTdates.length;i++){
                                      var start = GMTdates[i] - timestamp;
                                      document.clock.elements["time" + i].value = calcTime(start);
                                      }
                                  window.setTimeout('go()',1000)
                                  }
                                  function toSt(n) {
                                  s = (n < 10)? "0":"";
                                  return s + n.toString();
                                  }

                              function calcTime(count) {
                                  if (count <= 0) {
                                      return "Abgelaufen";
                                      }
                                  var secs = toSt(count % 60);
                                  count = Math.floor(count / 60);
                                  var mins = toSt(count % 60);
                                  count = Math.floor(count / 60);
                                  var hours = toSt(count % 24);
                                  count = Math.floor(count / 24);
                                  var days = count;
                                  return days + "T " + hours + ":" + mins + ":" + secs;
                                  }
                                  // -->
                                  </script>
                              ------------------------------

                              eigentlich dachte ich mir, wenn ich von beiden timestamps das offset abziehe, bringe ich sie beide wieder rechnerisch auf ein niveau. wenn anfangs- oder endzeit durch die sommerzeit sozusagen eine zeitzone weiter verschoben ist, hat sie ja auch ein höheres offset.
                              da es ja für die berechnung der verbleibenden sekunden nur auf die differenz der beiden ankommt, ist der tatsächliche timestamp irrelevant.

                              obwohl beide offsets jetzt -3600 sind, habe ich aber trotzdem eine stunde abweichung (zu viel) und ich kann mir nicht erklären, warum.

                              freundl. Grüsse aus Berlin, Raik

                              1. Hi,

                                bist Du Dir da sicher? Der timestamp ist doch lediglich die Zahl der verstrichenden Millisekunden. Erst die Date-Funktion macht daraus eine Sommer- oder Winterzeit.

                                nein, inzwischen bin ich mir wieder über garnichts mehr sicher. :-(

                                probier's doch einfach mal völlig ohne offset. Also z.B.

                                serverseitig generiert:
                                var servertimestampLadezeit = 1099321500000;
                                var servertimestampAblauf   = 1099322000000;

                                und clientseitig:
                                var clienttimestampLadezeit = new Date().getTime();

                                Um ungenaue Systemzeiten beim client auszuschließen, könnte man nun die Zeiten egalisieren:
                                var korrektur = servertimestampLadezeit - clienttimestampLadezeit;

                                Und die jeweilige Restzeit müßte dann zu berechnen sein über:
                                var restzeit = servertimestampAblauf - new Date().getTime() - korrektur;

                                freundliche Grüße
                                Ingo

                                1. Hallo, Ingo!

                                  serverseitig generiert:
                                     var servertimestampLadezeit = 1099321500000;
                                     var servertimestampAblauf   = 1099322000000;
                                  und clientseitig:
                                     var clienttimestampLadezeit = new Date().getTime();
                                     var korrektur = servertimestampLadezeit - clienttimestampLadezeit;
                                     var restzeit = servertimestampAblauf - new Date().getTime() - korrektur;

                                  so, hab ich eingebaut.
                                  ergebnis: die gleiche abweichung von +1std, wie bei meiner lösung.
                                  zusätzlich beim zurückstellen der systemzeit um einen monat (sommerzeit) eine weitere stunde abweichung (+1std), die bei meiner lösung nicht auftritt.
                                  dafür bei meiner lösung eine zusätzliche stunde abweichung bei der umstellung der systemzeit auf gtm/utc, die bei deiner lösung nicht auftritt.

                                  freundl. Grüsse aus Berlin, Raik

                              2. Moin,

                                var timestamp = 1099272882359; var zeit=new Date(); zeit.setTime(timestamp);

                                Das kannt man auch zusammenschreiben zu var zeit=new Date(timestamp);  (Ja, die Möglichkeit fehlte bisher in Selfhtml, das ist in 8.1 korrigiert.)

                                var offset = dat.getTimezoneOffset()*60;
                                        GMTdates[Nr] = stamp + offset;

                                Was soll das werden? Mach dir doch erst mal den Unterschied zwischen Zeitpunkten und bestimmten Repräsentationen davon klar. Ein Zeitpunkt ist ein universales Ding, völlig unabhängig vom Ort (naja, die Relativitätstheorie lassen wir mal beiseite ;). Das ist wie bei anderen physikalischen Größen, wie etwa Längen: Die Länge eines Objektes ist unabhängig von der Einheit in der du sie angibst.

                                Date-Objekte stellen Zeit_punkte_ dar, und keine bestimmten Zahlenwerte in irgendeiner Zeitzone. Eine im wesentlichen äquivalente Darstellung erreicht man jetzt über Timestamps, also die Differenz zu einem bestimmten Zeitpunkt auf den man sich geeignigt hat. (In der Längenanalogie wäre das der Größenvergleich mit dem Urmeter: Ob du eine Länge in cm, Angström oder Furlongs angibt macht dann keinen Unterschied, wichtig ist das Verhältnis zum Urmeter.)

                                Bei Timestamps ist normalerweise der 1. Januar 1970, 0:00:00 GMT der Bezugspunkt (beachte die Angabe der Zeitzone, das ist äquivalent der Angabe einer Längeneinheit: nur "1. Januar 1970, 0:00:00" zu sagen wäre wie wenn man sagen würde "Dieser Stock ist 17 lang"). Wir erinnern uns: Das ist ein Zeitpunkt angegeben in einer bestimmten Zeitzone. Der gleiche Zeitpunkt wäre zum Beispiel 1. Januar 1970, 1:00:00 CET. Oder als Timestamp ausgedrückt "0".

                                Da oben tust du aber etwas merkwürdiges und ziehst irgendwas von einem Timestamp ab oder addierst hinzu. Der Timestamp bezeichnet dann nicht mehr den gleichen Zeitpunkt, sondern irgendeinen anderen, das willst du sicher nicht.

                                Um das eigentliche Problem zu lösen solltest du erstmal versuchen deine Zeitangaben so lange wie möglich in Timestamp-Form zu halten, das ist wesentlich weniger verwirrend. Ähnlich wie du nicht einfach so 30m von 4 Furlongs abziehen kannst, kannst du mit "1.11.2004 22:30:17 CET" und "3.11.2004 17:15:03 EST" nicht direkt rechnen.

                                Besorge dir also die drei Zeiten mit denen du rechnen musst zunächst in Timestamp-Format: Die aktuelle Serverzeit kriegst du geschenkt, die aktuelle Client-Zeit ebenso fast (halt ein neues Date-Objekt erzeugen und dann getTime() rufen). Damit kannst du relativ einfach die Serverzeit auf dem Client interpolieren (beim Laden die Differenz zwischen Serverzeit und Clienzeit bilden und die dann später auf die Clientzeit aufschlagen).

                                Deine Endzeitpunkte solltest du ebenso als Timestamp verwalten (wir erinnern uns: Timestamps und Zeitzonen haben absolut nichts miteinander zu tun). Das kommt drauf an wo du die herkriegst, ob sie da schon als Timestamps vorliegen oder du sie erst umrechnen musst (wenn du von einer Datumsangabe in einen Timestamp umrechnest musst du halt beachten in welcher Zeitzone das Datum angegeben ist).

                                Die Restzeit bis zum Ende kannst du jetzt trivial durch Subtraktion ermitteln. Beachte, dass hier nirgendwo auch nur der Hauch einer Zeitzone auftaucht, denn solange du nur mit Zeitpunkten intern agieren musst spielen die einfach keine Rolle. Etwas anders wird das ggbf. wenn du mal einen Zeitpunkt (und nicht nur eine Differenz, die ist ja unabhängig von Zeitzonen) an den Benutzer ausgeben musst. Im Prinzip ist es ok, einfach nur die Zeit in GMT auszugeben (benutze dazu die getUTC*()-Funktionen des Date-Objektes), nett wäre es ggbf. die Zeit in Lokalzeit anzugeben (benutze dazu die get*()-Funktionen). Die Zeitzone die du verwendest musst du in jedem Fall angeben.

                                Alle Komplikationen was Sommerzeit/Winterzeit oder Konvertierung in Lokalzeit angeht muss aber das Date-Objekt für dich übernehmen, da hast du nichts weiter mit zu schaffen als eine Funktion für "Gib mir den Stundenteil in lokaler Zeit" aufzurufen. Insbesondere hast du nicht an den Timestamps rumzumachen, da damit ja dann andere Zeitpunkte gemeint sind.

                                --
                                Henryk Plötz
                                Grüße aus Berlin
                                ~~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~~
                                ~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~~
                                1. Hallo, Henryk!

                                  vielen dank nochmal für deine erklärungen.
                                  das prinzip des timestamps war mir auch schon klar. ich konnte mir nur die eine stunde differenz nicht erklären.
                                  ich habe jetzt festgestellt, dass ich bei der umwandlung der endzeit auf dem server mit
                                  $timestamp = strtotime($row['EndeZeit']);
                                  auch die zeitverschiebung auf dem server zu gmt berücksichtigen muss:
                                  $timestamp = strtotime($row['EndeZeit'])-Date("Z");
                                  weil das strtotime() wohl nicht selber tut.

                                  freundl. Grüsse aus Berlin, Raik

                                  1. Moin,

                                    das prinzip des timestamps war mir auch schon klar. ich konnte mir nur die eine stunde differenz nicht erklären.

                                    Naja, offensichtlich nicht, sonst würdest du nicht schon wieder an einem Timestamp herumaddieren und trotzdem glauben damit immer noch den gleichen Zeitpunkt zu meinen.

                                    ich habe jetzt festgestellt, dass ich bei der umwandlung der endzeit auf dem server mit
                                    $timestamp = strtotime($row['EndeZeit']);
                                    auch die zeitverschiebung auf dem server zu gmt berücksichtigen muss:
                                    $timestamp = strtotime($row['EndeZeit'])-Date("Z");
                                    weil das strtotime() wohl nicht selber tut.

                                    Warum solltest du? Wie schon gesagt: Der Timestamp hat ü-ber-haup-nichts mit irgendeiner Zeitzone zu tun, insbesondere kann man nicht einfach so ungestraft irgendein Offset dazuaddieren und glauben damit durchzukommen. Wenn du das Gefühl hast dein errechneter Timestamp würde danebenliegen dann ist das wahlweise ein Bug ein strtotime (das glaube ich aber nicht) oder du hast schon vorher einen Fehler. Was steht denn in $row['EndeZeit'] und wo kommt es her?

                                    Die ebay-Seiten geben soweit ich sehen kann korrekterweise zu allen Zeiten die Zeitzone an. Allerdings halt in der jeweiligen Landessprache (genau wie das Datum), was zumindest im Fall von Deutsch von strtotime nicht so gerne gefressen wird.

                                    --
                                    Henryk Plötz
                                    Grüße aus Berlin
                                    ~~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~~
                                    ~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~~
                                    1. Hallo, Henryk!

                                      Wenn du das Gefühl hast dein errechneter Timestamp würde danebenliegen dann ist das wahlweise ein Bug ein strtotime (das glaube ich aber nicht) oder du hast schon vorher einen Fehler. Was steht denn in $row['EndeZeit'] und wo kommt es her?

                                      2004-11-02 21:31:22

                                      das ist das format (datetime), das biet-o-matic in die mysql-datenbank schreibt.
                                      und strtotime interpretiert das als gmt-datum, weil nichts zusätzlich angegeben ist und übernimmt damit mein lokales offset von +0100 .
                                      ich könnte jetzt natürlich den zusatz recherchieren und von hand dazuschreiben. dann ist das script aber nicht mehr ohne änderung in anderen ländern einzusetzen. zum glück liefert mir Date("Z") aber das offset des rechners, auf dem das script ausgeführt wird, so dass ich den durch das fehlende zeitzonenkürzel entstandenen fehler wieder ausgleichen kann.

                                      $timestamp = strtotime(1970-00-00 00:00:00)     -> -1 (fehler bei der berechnung, da windows-system mit kaputter systembibliothek, siehe doku)
                                      $timestamp = strtotime(1970-00-00 00:00:00 GMT) ->  0 (richtig)
                                      $timestamp = strtotime(1970-00-00 01:00:00)     ->  0 (richtig)
                                      $timestamp = strtotime(1970-00-00 01:00:00 GMT) ->  3600 (richtig)

                                      ich handle mir also mangels zeitzonen-kürzel 3600 sekunden fehler ein, die ich wieder abziehen muss, um auf den richtigen gmt-timestamp zu kommen.

                                      Die ebay-Seiten geben soweit ich sehen kann korrekterweise zu allen Zeiten die Zeitzone an. Allerdings halt in der jeweiligen Landessprache (genau wie das Datum), was zumindest im Fall von Deutsch von strtotime nicht so gerne gefressen wird.

                                      und biet-o-matic liest die nicht mit aus , sondern hat das für den server (.de, .co.uk, .com) jeweils gültige offset in stunden in der ServerStrings.ini stehen:
                                          [DateTime]
                                          ;format
                                          ansDateFormat="dd.mm.yy HH:mi:ss"
                                          ; Offset to UTC
                                          ansOffsetLocal1=2
                                          ansOffsetLocal2=1

                                      vielen dank nochmal für deine hilfe. in zukunft werde ich damit keine probleme mehr haben, denke ich.

                                      freundl. Grüsse aus Berlin, Raik

                                      1. Moin,

                                        2004-11-02 21:31:22

                                        das ist das format (datetime), das biet-o-matic in die mysql-datenbank schreibt.

                                        Na dann ist das Programm kaputt und du solltest da ansetzen das zu reparieren. Was passiert denn wenn das Programm dass die Daten einträgt und das welches die Daten nachher ausliest in verschiedenen Zeitzonen liegen? -> selbst reparieren oder mindestens Bugreport

                                        Bzw. schlimmer noch, da du ja DATETIME als Spaltenformat hast und man da überhaupt keine Zeitzone mitgeben kann wäre es die Aufgabe des eintragenden Programms daraus etwas zu basteln von dem man nachher sicher sagen kann in welcher Zeitzone es gemeint ist, also für alle praktischen Anwendungsfälle sollte die Zeit nach GMT konvertiert werden. (Oder man schreibt in dicken roten Lettern auf die erste Seite der Doku "Die Zeiten werden in <sonstwas> angegeben." Ein "die Zeiten sind in der Zeitzone unter der das Programm zufällig grade lief" ist jedenfalls inakzeptabel.)

                                        und strtotime interpretiert das als gmt-datum, weil nichts zusätzlich angegeben ist

                                        Was ja auch richtig ist. Eine Zeitangabe ohne Angabe der Zeitzone ist vollkommen unbrauchbar, und kann praktisch in jeder der möglichen Zeitzonen gemeint sein.

                                        und biet-o-matic liest die nicht mit aus , sondern hat das für den server (.de, .co.uk, .com) jeweils gültige offset in stunden in der ServerStrings.ini stehen:

                                        *inTischkanteBeiß* Ahrg! Wirklich professionelle Software...

                                        --
                                        Henryk Plötz
                                        Grüße aus Berlin
                                        ~~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~~
                                        ~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~~
                                        1. Hallo, Henryk!

                                          2004-11-02 21:31:22
                                          das ist das format (datetime), das biet-o-matic in die mysql-datenbank schreibt.
                                          Na dann ist das Programm kaputt und du solltest da ansetzen das zu reparieren. Was passiert denn wenn das Programm dass die Daten einträgt und das welches die Daten nachher ausliest in verschiedenen Zeitzonen liegen? -> selbst reparieren oder mindestens Bugreport

                                          das wird wohl zumindest in meinem fall kaum vorkommen, weil ich das als paket bereitstellen will, welches auf dem gleichen rechner, wie bom läuft. ...

                                          Bzw. schlimmer noch, da du ja DATETIME als Spaltenformat hast und man da überhaupt keine Zeitzone mitgeben kann wäre es die Aufgabe des eintragenden Programms daraus etwas zu basteln von dem man nachher sicher sagen kann in welcher Zeitzone es gemeint ist, also für alle praktischen Anwendungsfälle sollte die Zeit nach GMT konvertiert werden. (Oder man schreibt in dicken roten Lettern auf die erste Seite der Doku "Die Zeiten werden in <sonstwas> angegeben." Ein "die Zeiten sind in der Zeitzone unter der das Programm zufällig grade lief" ist jedenfalls inakzeptabel.)

                                          ... aber du hast natürlich nicht unrecht. eleganter wäre eine umrechnung auf gmt und speicherung als timestamp.

                                          *inTischkanteBeiß* Ahrg! Wirklich professionelle Software...

                                          nein, opensource, von freiwilligen in ihrer freizeit entwickelt. bei denen wird man wohl keine forderungen stellen können. übrigens steht es dir frei, dich dort mit einzubringen ;-). du kannst doch vb? *gg*

                                          freundl. Grüsse aus Berlin, Raik

                                          1. Moin,

                                            das wird wohl zumindest in meinem fall kaum vorkommen, weil ich das als paket bereitstellen will, welches auf dem gleichen rechner, wie bom läuft. ...

                                            Ausser natürlich wenn die Daten vor der Sommerzeitumstellung eingetragen wurden und das PHP-Skript danach läuft ... oder zwischenzeitlich die Zeitzone aus anderen Gründen umgestellt wurde ...

                                            nein, opensource, von freiwilligen in ihrer freizeit entwickelt.

                                            Umso schlimmer, in der Zeit in der dieser Hack entwickelt wurde hätte man sinnvolle Sachen tun können

                                            bei denen wird man wohl keine forderungen stellen können.

                                            Achwas. All software sucks. All hardware sucks.

                                            übrigens steht es dir frei, dich dort mit einzubringen ;-). du kannst doch vb? *gg*

                                            Noe, wieso sollte ich. Ich mach auch nicht mit Windows-Saftware rum.

                                            --
                                            Henryk Plötz
                                            Grüße aus Berlin
                                            ~~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~~
                                            ~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~~
                                            1. Hallo, Henryk!

                                              das wird wohl zumindest in meinem fall kaum vorkommen, weil ich das als paket bereitstellen will, welches auf dem gleichen rechner, wie bom läuft. ...
                                              Ausser natürlich wenn die Daten vor der Sommerzeitumstellung eingetragen wurden und das PHP-Skript danach läuft ... oder zwischenzeitlich die Zeitzone aus anderen Gründen umgestellt wurde ...

                                              autsch! das stimmt natürlich. ich muss also das offset des jeweiligen datums bestimmen, statt einfach pauschal das gerade aktuelle offset abzuziehen.
                                              hab denen schon ins board geschrieben, dass die umwandlung auf gmt und speicherung als timestamp besser wäre.

                                              nein, opensource, von freiwilligen in ihrer freizeit entwickelt.
                                              Umso schlimmer, in der Zeit in der dieser Hack entwickelt wurde hätte man sinnvolle Sachen tun können

                                              z.b.? PARAGON Last Minute Gebot _kaufen_ ? (bist du des wahnsinns?!?)
                                              ich bin ja schon froh, dass überhaupt jemand freiwillig kostenlos sowas entwickelt. verbessern kann man es ja immer noch ..
                                              (auch wenn ich dafür nicht ausgerechnet vb gewählt hätte ;-) ).

                                              übrigens steht es dir frei, dich dort mit einzubringen ;-). du kannst doch vb? *gg*
                                              Noe, wieso sollte ich. Ich mach auch nicht mit Windows-Saftware rum.

                                              moderne programmiersprachen sollen sich doch angeblich (fast) ohne änderungen für viele plattformen kompilieren lassen?

                                              freundl. Grüsse aus Berlin, Raik

                                      2. Hi,

                                        und biet-o-matic liest die nicht mit aus , sondern hat das für den server (.de, .co.uk, .com) jeweils gültige offset in stunden in der ServerStrings.ini stehen:

                                        nur mal interessehalber gefragt: welchen Offset haben diesem Programm nach .com-Domains?

                                        Und in einigen Ländern dürfte das dann auch überhaupt nicht funktionieren:
                                        <zitat>So liegen zum Beispiel der Iran dreieinhalb Stunden, Afghanistan viereinhalb Stunden, Indien fünfeinhalb Stunden, und die australischen Bundesstaaten „Northern Territory“ und „Southern Territory“ neuneinhalb Stunden vor der Greenwich Mean Time.</zitat>

                                        freundliche Grüße
                                        Ingo

                                        1. Hallo, Ingo!

                                          und biet-o-matic liest die nicht mit aus , sondern hat das für den server (.de, .co.uk, .com) jeweils gültige offset in stunden in der ServerStrings.ini stehen:
                                          nur mal interessehalber gefragt: welchen Offset haben diesem Programm nach .com-Domains?

                                          .co.uk
                                            [DateTime]
                                            ;format
                                            ansDateFormat="dd-MMM-yy HH:mi:ss"
                                            ; Offset to UTC
                                            ansOffsetLocal1=1
                                            ansOffsetLocal2=0

                                          .com
                                            [DateTime]
                                            ;format
                                            ansDateFormat="MMM-dd-yy HH:mi:ss"
                                            ; Offset to UTC
                                            ansOffsetLocal1=-7
                                            ansOffsetLocal2=-8

                                          wobei sich diese offsets nicht die länder der nutzer beziehen, sondern auf den standort des servers von ebay und dessen "zeitrechnung".

                                          Und in einigen Ländern dürfte das dann auch überhaupt nicht funktionieren:
                                          <zitat>So liegen zum Beispiel der Iran dreieinhalb Stunden, Afghanistan viereinhalb Stunden, Indien fünfeinhalb Stunden, und die australischen Bundesstaaten „Northern Territory“ und „Southern Territory“ neuneinhalb Stunden vor der Greenwich Mean Time.</zitat>

                                          wenn ebay da auch server hinstellt, die sich nach der lokalen zeit dort richten, müssen die dortigen user halt selber eine ini mit den passenden werten erstellen.

                                          b.t.w. vielen dank auch nochmal für deine hilfe. alleine würde ich wohl immer noch daran knobeln.

                                          freundl. Grüsse aus Berlin, Raik

                                          1. Hi,

                                            wobei sich diese offsets nicht die länder der nutzer beziehen, sondern auf den standort des servers von ebay und dessen "zeitrechnung".

                                            na dann paßt das ja mit .com.

                                            wenn ebay da auch server hinstellt, die sich nach der lokalen zeit dort richten, müssen die dortigen user halt selber eine ini mit den passenden werten erstellen.

                                            wenn das überhaupt geht bzw. das Script 0.5 Stunden akzeptiert.

                                            b.t.w. vielen dank auch nochmal für deine hilfe. alleine würde ich wohl immer noch daran knobeln.

                                            bitteschön. War ich ja aber nicht alleine...
                                            Übrigens habe ich jetzt auch für meine Sommerzeitberechnung herausgefunden, daß es leider kein neutrales Vergleichsdatum mit einheitlicher Winterzeit gibt. Die Länder auf der Südhalbkugel stellen meist exakt zur Selben Zeit auf Sommerzeit um wie wir auf Winterzeit. Wobei es in Australien übrigens sogar noch regionale Unterschiede gibt (und teilweise sogar 1/2-Stundenabweichungen). Puh...;-)

                                            freundliche Grüße
                                            Ingo

                                2. Hi,

                                  da lag ich ja mit meiner letzten Theorie sogar richtig. :-)

                                  Alle Komplikationen was Sommerzeit/Winterzeit oder Konvertierung in Lokalzeit angeht muss aber das Date-Objekt für dich übernehmen,

                                  allerdings mit einer Ausnahme, wie ich im Verlauf dieses Threads festgestellt habe: die Endzeit darf nicht im Zeitraum der Umstellung liegen. Aber das kommt ja wohl kaum vor.

                                  freundliche Grüße
                                  Ingo

                                  1. Moin,

                                    allerdings mit einer Ausnahme, wie ich im Verlauf dieses Threads festgestellt habe: die Endzeit darf nicht im Zeitraum der Umstellung liegen. Aber das kommt ja wohl kaum vor.

                                    Noe, wieso? Es muß halt immer die richtige Zeitzone dahinter stehen: Nach "31.19.2004 01:59:59 CEST" kommt "31.10.2004 02:00:00 CEST" und dann später nach "31.10.2004 02:59:59 CEST" kommt "31.10.2004 02:00:00 CET". Die Timestamps müssen ja während der gesamten Zeit streng monoton wachsen.

                                    --
                                    Henryk Plötz
                                    Grüße aus Berlin
                                    ~~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~~
                                    ~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~~
                                    1. Hi,

                                      allerdings mit einer Ausnahme, wie ich im Verlauf dieses Threads festgestellt habe: die Endzeit darf nicht im Zeitraum der Umstellung liegen. Aber das kommt ja wohl kaum vor.

                                      Noe, wieso? Es muß halt immer die richtige Zeitzone dahinter stehen: Nach "31.19.2004 01:59:59 CEST" kommt "31.10.2004 02:00:00 CEST" und dann später nach "31.10.2004 02:59:59 CEST" kommt "31.10.2004 02:00:00 CET". Die Timestamps müssen ja während der gesamten Zeit streng monoton wachsen.

                                      Das tun sie ja auch. aber wie ich in https://forum.selfhtml.org/?t=93166&m=564179 festgestellt hatte nur dann, wenn der Rechner durchläuft und eine Chance hat, die Zeitumstellung mitzubekommen.

                                      Wenn Du aber einen Endzeitpunkt mitten in dieser Umstellungsphase bestimmen mußt, also z.B. 31.10.04 02:35 (Sommerzeit), dann liefert Dir Date() stets Winterzeit, also Sun Oct 31 02:35:00 UTC+0100 2004. Wie sollte Date() auch wissen, welche der 2 Möglichkeiten für dieses Datum zutrifft? Der Timestamp entspricht also dem des zweiten Durchlaufs dieser Uhrzeit. Über die UTC-Funktionen dürfte das Problem aber wegfallen.

                                      freundliche Grüße
                                      Ingo

      2. Hallo!

        sowohl

        <?php
        echo date("O");       # gibt +0200 aus
        ?>

        als auch

        <script type="text/javascript">
        <!--
          var jetzt = new Date();
          var Unterschied = jetzt.getTimezoneOffset() / 60;
          alert("Unterschied zu Greenwich: " + Unterschied + " Stunde(n)");    // gibt 2 aus
        }
        </script>

        ergeben zwei stunden zeitdifferenz zu gmt.
        woher kommt jetzt die zusätzliche stunde und warum nur bei >= 24 stunden?

        freundl. Grüsse aus Berlin, Raik

  2. Hi,

    //ich übergebe mit php den timestamp
    var Start = 1099342194;

    Eine Winterzeit am 1. November...

    d = new Date();
    count = Math.floor(Start - (d.getTime()/1000));

    die Differenz zwischen der aktuellen Sommerzeit und der Zeit am 1. November.

    Da dazwischen eine Stunde doppelt gezählt wird, ist die Ausgabe doch eigentlich korrekt, oder?

    freundliche Grüße
    Ingo