PHP / MySQL / Linux Stories

Eigentlich war ich ziemlich begeistert, vom DateTime Objekt. Endlich richtig einfach mit Daten umgehen und das auch noch inkl Zeitzonen etc.
Seitdem ich allerdings mit einem Kollegen einen wirklich “krassen” Bug fand, bin ich nicht mehr so begeistert!

Reproduzierbar ist er folgendermaßen:

$from = new DateTime();
$from->setTime(0, 0, 0);
$from->setISODate(2010, 28, 1); //Montag der 28ten Woche 2010
 
echo $from->format('d.m.Y H:i'); //A
echo $from->getTimestamp(); //B
echo date('Y-m-d H:i', $from->getTimestamp()); //C

A: das ausgegeben Datum stimmt, es ist der 12.07.2010
B: der Timestamp ist viel zu hoch: 1291849200
C: der Beweis, der Timestamp gehört zum 29.05.2011 00:00

Wir haben lange versucht herauszufinden, warum dies passiert. Ein hässlicher Workaround ist dieser:

$from->add(new DateInterval('P0D'));

Wir fügen also ein Interval von 0 Tagen (oder Stunden, Minuten etc) hinzu, wodurch sich eigentlich nichts ändern sollte. Danach stimmt das Ergebnis von ->getTimestamp() allerdings, nämlich 1278885600.

Nachdem wir absolut keinen Grund feststellen konnten, haben wir das Vertrauen verloren und nutzen seitdem Zend_Date, welches, meiner Meinung nach, besser und einfacher zu bedienen ist. Das ZendFramework ist sowieso schon im aktuellen Projekt eingebunden (nicht als Framework an sich, eher als Klassensammlung), als sprach es auch nicht dagegen, einen riesen Klotz an Dateien/Klassen zu integrieren, um nur eine Klasse zu nutzen.

$date = new Zend_Date();
$date->setWeek(28)->setYear(2010)->setWeekday(1);
$date->setHour(0)->setMinute(0)->setSecond(0);
echo $date->getTimestamp();

Liefert das erwartete Ergebnis: 1278885600

Ist das nun wirklich ein riesen DateTime Bug oder liegt ein Denkfehler unsererseits vor?

Geschrieben am Mittwoch, Juli 14th, 2010 um 22:14 und ist zu finden in php. Du kannst die Antworten zu diesem Thema verfolgen unter: RSS 2.0 feed. Du kannst Antwort, or trackback von deiner Seite.