Rechnet der Datepicker falsch?

[Samson1964]

Ich habe ein Problem mit dem Datepicker im DCA. Folgende Datumsangaben verwandte ich in meinem Test, zuerst das eingebene Datum, danach der gespeicherte Timestamp und in Klammern das aufgrund des Timestamps ermittelte Datum:

05.10.1947 = -701920800 (unixtime.de: 05.10.1947 - 00:00:00)
06.10.1947 = -701830800 (unixtime.de: 06.10.1947 - 00:00:00)
07.10.1947 = -701744400 (unixtime.de: 07.10.1947 - 00:00:00)

Wenn man jetzt die Differenzen ermittelt, kommt man zwischen 5. und 6.10.47 auf 90.000 Sekunden, also 1 Stunde mehr! Und genau das wird zum Problem. Beim Übermitteln der Timestamps an einen anderen Server (vom DOSB) über eine API, errechnete der Server für den ersten Timestamp den 04.10.1947 23:00:00. Das finde ich soweit richtig, weil es ja 90.000 Sekunden sind.

Die IT des DOSB-Servers konnte keine Unregelmäßigkeiten feststellen und schlugen mir vor, einen Timestamp weit entfernt von 00:00 Uhr zu übermitteln, um diesen Problemen aus dem Weg zu gehen.

Wer rechnet denn nun hier falsch? Warum sind da 90.000 statt 86.400 Sekunden Differenz? Was macht der DOSB-Server richtig und was Contao/unixtime.de falsch - oder umgekehrt?

[Andreas]

Ich habe mal ein wenig getestet.

PHP ermittelt mit strtotime() tatsächlich aus

05.10.1947 => -701920800
06.10.1947 => -701830800

was einer Differenz von 90000 entspricht (richtig wären 86400). Selbst mit angegebener Uhrzeit 00:00:00 bekommt man diese Werte.

05.10.1947 00:00:00 => -701920800
06.10.1947 00:00:00 => -701830800

Aber beim Zurückwandeln mit date() gibt es wieder das richtige Datum.

-701920800 => 05.10.1947 00:00:00
-701830800 => 06.10.1947 00:00:00

PHPs DateTime::createFromFormat($format, $date)->getTimestamp() ermittelt übrigens die gleichen Werte. Bis auf den Unterschied, dass man bei createFromFormat() die Uhrzeit 00:00:00 mit angeben muss, sonst nimmt es die aktuelle Uhrzeit.

Ob das an der Umstellung von der Sommerzeit liegt?

Calc aus OOo z.B. ermittelt aus diesen Timestamps folgende Datums (=ZELLE/86400+25569)

-701920800 => 05.10.1947 22:00:00
-701830800 => 06.10.1947 23:00:00

Hier mein Script, mit dem ich getestet habe:

<?php

$date = '.10.1947 00:00:00';
$formatIn  = 'd.m.Y H:i:s'; // anpassen an $date
$formatOut = 'd.m.Y H:i:s';

foreach(array('05', '06', '07') as $day)
{
  echo $day.$date.'<br><br>';

  echo 'timestamp with strtotime()<br>';
  dump(strtotime($day.$date));
  echo 'readable with date()';
  dump(date($formatOut, strtotime($day.$date)));
  echo 'readable with \Date::parse()';
  dump(\Date::parse($formatOut, strtotime($day.$date)));

  echo 'timestamp with DateTime';
  dump(DateTime::createFromFormat($formatIn, $day.$date)->getTimestamp());
  echo 'readable with date()';
  dump(date($formatOut, DateTime::createFromFormat($formatIn, $day.$date)->getTimestamp()));
  echo '<hr>';
}

?>

edit: \Date:arse() hinzugefügt

[Andreas]

Scheint ganz einfach wirklich mit der "Daylight Saving Time" zu tun zu haben. Das heißt es gibt Tage mit 86400, 90000 und 82800 Sekunden. Habe nach "php timestamp 90000" gesucht.

[Hanski]

siehe auch

http://www.ptb.de/cms/ptb/fachabteilungen/abt4/fb-44/ag-441/darstellung-der-gesetzlichen-zeit/sommerzeiten-und-hochsommerzeiten-in-deutschland-bis-1979.html

[Andreas]

Und hier ne Auflistung mit PHP

<?php

$years = range(1900, 2020);

echo '<pre>';
foreach($years as $year)
{
  echo $year."\n";

  for($month = 1; $month <= 12; $month++) {

    for($day = 1; $day <= 31; $day++) {
      if(checkdate($month, $day, $year))
      {
        $i++;
        $timestamp = strtotime($day.'.'.$month.'.'.$year);
        $arrTimestamp[$i] = $timestamp;
        if($i > 1 && $arrTimestamp[$i] - $arrTimestamp[$i-1] != 86400)
        {
          echo date('D d. M Y', $timestamp).' - '.($arrTimestamp[$i] - $arrTimestamp[$i-1])."\n";
        }
      }
    }
  }
}
echo '</pre>';

?>

[folkfreund]

siehe auch
http://www.ptb.de/cms/ptb/fachabteil...-bis-1979.html

Wird dieses 'Zeitchaos' von PHP abgebildet?

Na ja, damals hat noch niemand vorhersehen können, dass wir heute mit Computern Zeitdifferenzen in diesen Jahren berechnen.
1970 wusste ja auch noch niemand, dass irgendwann mal 2038 sein würde .

[Andreas]

Wird dieses 'Zeitchaos' von PHP abgebildet?

Ich habe oben noch die Ausgabe als Bild hinzugefügt.

[Samson1964]

Wow, danke für die Erläuterungen. Nicht GMT+1 ist die Ursache, sondern die Sommerzeit. Das heißt für mich, das der DOSB-Server die Sommerzeit berücksichtigt und mein Server nicht. Muss ich wohl tatsächlich ein paar Stunden addieren, bevor ich den timestamp zum DOSB-Server abschicke.

Gesendet von meinem L52 mit Tapatalk

[Spooky]

Timestamps sind absolute Werte. Erkläre mal dein Vorhaben.

[Samson1964]

Siehe mein erster Beitrag. Wenn ich den timestamp -701920800 also 05.10.1947 00:00:00 an den DOSB-Server übertragen, ermittelt der DOSB-Server daraus den 04.10.1947 23:00:00. Die DOSB-IT sagt, bei uns ist alles korrekt. Vorschlag der DOSB-IT war einfach bei meinem timestamp 1 oder mehr Stunden zu addieren. Meine Vermutung: der DOSB-Server steht in einem Land das keine Zeitumstellung kennt und deshalb den timestamp anders umrechnen.

Gesendet von meinem L52 mit Tapatalk

[fiedsch]

Meine Vermutung: der DOSB-Server steht in einem Land das keine Zeitumstellung kennt und deshalb den timestamp anders umrechnen.

Aber ist es nicht so, daß Timestamps alle "in GMT" sein sollten und es somit egal ist wo af der Welt Du bist.

[Spooky]

Siehe mein erster Beitrag. Wenn ich den timestamp -701920800 also 05.10.1947 00:00:00 an den DOSB-Server übertragen, ermittelt der DOSB-Server daraus den 04.10.1947 23:00:00.

Wahrscheinlich weil sich der Server in eben dieser Zeitzone befindet. Das ist normal. -701920800 entspricht Oct 04 1947 23:00:00 in GMT DST.

Meine Vermutung: der DOSB-Server steht in einem Land das keine Zeitumstellung kennt und deshalb den timestamp anders umrechnen.

So funktionieren Timestamps nicht . Timestamps sind immer gleich.

[Andreas]

Calc aus OOo z.B. ermittelt aus diesen Timestamps folgende Datums (=ZELLE/86400+25569)

-701920800 => 05.10.1947 22:00:00
-701830800 => 06.10.1947 23:00:00

Calc scheint das ja auch nicht richtig umwandeln zu können.