PHPGangsta - Der praktische PHP Blog

Gastartikel von Arno Hollosi.

Kurz zu meiner Person: Ich arbeite seit über 13 Jahren mit PHP, betreibe ein recht erfolgreiches Wiki (Sensei’s Library) und habe in den letzten Jahren zwei Bücher veröffentlicht: PHP programmieren unter Windows (auch ins Englische übersetzt) und  das vor kurzem hier verloste Buch Leistungsstarke PHP-Anwendungen.

Wenn Ihr genaue Uhrzeiten in eurer Applikation verwalten müsst, merkt ihr bald, dass das Thema komplexer als angenommen ist: Nicht nur, dass die Erde eine Kugel ist, nein, zudem hat sich Anfang des vergangenen Jahrhunderts die Idee der Sommerzeit durchgesetzt und auch Regierungen ändern gelegentlich die Zeit ihres Landes.

Sommerzeit

Egal was ihr von der Sommerzeit haltet, in den PHP-Anwendungen kann man sich als Programmierer vor der Sommerzeit nicht drücken. Leider ist das genaue Datum der Umstellung von Land zu Land und teilweise sogar von Jahr zu Jahr unterschiedlich. Zudem gibt es Zonen, in denen der Unterschied zwischen Sommer- und Winterzeit nicht eine Stunde beträgt, auf der Lord-Howe-Insel in Australien wird z.B. die Uhr nur um eine halbe Stunde verstellt. In PHP erhält man die aktuellen Angaben mit DateTimeZone::getTransitions():

 $tz = new DateTimeZone('Europe/Berlin');
$transitions = $tz->getTransitions(time());
print_r($transitions[0]); // Angaben zur aktuellen Zeit
print_r($transitions[1]); // Nächster Wechsel
print_r($transitions[2]); // Übernächster Wechsel etc.

Array ( [ts] => 1346686784 [time] => 2012-09-03T15:39:44+0000
        [offset] => 7200 [isdst] => 1 [abbr] => CEST )

Array ( [ts] => 1351386000 [time] => 2012-10-28T01:00:00+0000
        [offset] => 3600 [isdst] => [abbr] => CET )

Array ( [ts] => 1364691600 [time] => 2013-03-31T01:00:00+0000
        [offset] => 7200 [isdst] => 1 [abbr] => CEST )

Wie spät war es doch gleich?

Die Grenzen der Zeitzonen und auch die Zugehörigkeit von Staaten zu Zeitzonen verändern sich immer wieder. Portugal beispielsweise wechselte 1966 von der Westeuropäischen zur Mitteleuropäischen Zeit, 1976 retour zur Westeuropäischen Zeit, 1992 zur Mitteleuropäischen Zeit und ist seit 1996 wieder in der Westeuropäischen Zeitzone. Alleine in Europa fanden seit den 1960er Jahren knapp 100 solcher Zeitzonenwechsel statt. Auch ob die Sommerzeit angewandt wird und wann sie startet und endet ändert sich gelegentlich. Kuba hat beispielsweise heuer den Start kurzfristig auf den 1. April verschoben ;o)

Olson-Datenbank

Die Zeitzonendatenbank (auch nach ihrem Gründer Olson-Datenbank genannt) enthält alle aktuellen und historischen Angaben zu den Zeitzonen. Von dieser Datenbank stammen auch die Kennungen Europe/Berlin oder America/Mexico_City. Die Datenbank enthält ca. 400 verschiedene Zeitzonen, da in der Definition der Datenbank eine Zeitzone eine Region ist, in der die Uhrzeiten seit 1970 übereinstimmen. Die Datenbank führt historische Daten teilweise bis zurück ins 19. Jahrhundert.

Eric Muller: The TZ timezones of the world (http://efele.net/maps/tz/world/)

Die Zeitzonendatenbank ist Bestandteil von PHP, muss also nicht extra installiert werden. Das hat aber auch einen Nachteil: die in PHP integrierte Datenbank wird nur aktualisiert, wenn ihr eine neue PHP-Version installiert. Da die Datenbank aber mehrmals pro Jahr aktualisiert wird, seid ihr möglicherweise nicht immer am aktuellsten Stand. Mithilfe von PECL kann man sich aber die aktuelle Version als Erweiterung installieren, die automatisch von den PHP-Datums- und -Zeitfunktionen verwendet wird. Mit pecl install timezonedb lässt sich die Erweiterung einfach installieren. Um auf dem aktuellen Stand zu bleiben, muss nur in Folge regelmäßig die PECL-Erweiterung aktualisiert werden: pecl upgrade timezonedb.

Zeitstempel

UTC-Zeitstempel, meist als Unix-Zeitstempel angegeben, eignen sich gut für das Festhalten von absoluten Zeitpunkten:

• Als (Server-)Uhrzeit für interne Protokollierung von Ereignissen
• Berechnung der Dauer seit einem Ereignis (z.B. Alter einer Nachricht, Zeit seit letztem Login)
• Berechnung von Zeitpunkten ausgehend von einem gegebenen UTC-Zeitpunkt und absoluten Intervallen (z.B. in 60 Minuten, vor 24 Stunden)

Für andere Aufgaben sind UTC-Zeitstempel wegen der Zeitzonen, Sommerzeit und politischen Änderungen nicht geeignet. Wenn eure Benutzer Termine in ihrer Ortszeit angeben können, solltet ihr von der UTC-Zeit im Regelfall die Finger lassen.

Zudem werden Unix-Zeitstempel als vorzeichenbehaftete 32-Bit-Zahl der Sekunden seit 1.1.1970 gespeichert, weshalb der mögliche Zeitraum nur von 1901-12-13 bis 2038-01-19 reicht. Wenn das Betriebssystem 64-Bit-Zeitstempel unterstützt, tut dies der PHP-Zeitstempel aber ebenfalls. Damit umfasst der Zeitraum ±292 Billionen Jahre, was für jede Anwendung ausreichend sein sollte 😉

DateTime

PHP bietet mit DateTime und den zugehörigen Klassen DateTimeZone, DateInterval und DatePeriod ausgereifte Werkzeuge zur Speicherung und Verarbeitung von Ortszeiten an. Intern arbeiten die Klassen mit 64 Bit, der mögliche Zeitraum ist also praktisch unbeschränkt.

Einen Zeitpunkt inklusive Zeitzone erzeugt man wie hier zu sehen, mit format() kann man die gewünschte Ausgabe erzeugen:

$tz = new DateTimeZone('Europe/Berlin');
$termin = new DateTime('2012-10-01 08:15:00', $tz);
printf("%s (%+.1f)", $termin->format('Y-m-d H:i'), $termin->getOffset()/3600);

2012-10-01 08:15 (+2.0) // Europe/Berlin

Um den Termin in eine andere Zeitzone umzurechnen, kann man mit setTimezone() die Zone ändern:

$tz2 = new DateTimeZone('Australia/Lord_Howe');
$termin->setTimezone($tz2);
printf("%s (%+.1f)", $termin->format('Y-m-d H:i'), $termin->getOffset()/3600);

2012-10-01 16:45 (+10.5)  // umgerechnet in Australia/Lord_Howe

Will man den Termin beispielsweise um zwei Wochen verschieben, verwendet man DateInterval. Das Intervall wird im ISO8601-Format angegeben:

$zweiWochen = new DateInterval('P2W');
$termin->add($zweiWochen);
printf("%s (%+.1f)", $termin->format('Y-m-d H:i'), $termin->getOffset()/3600);
$termin->setTimezone($tz); // Wieder Europe/Berlin
printf("%s (%+.1f)", $termin->format('Y-m-d H:i'), $termin->getOffset()/3600);

2012-10-15 16:45 (+11.0) // + 2 Wochen (in Australia/Lord_Howe)

2012-10-15 07:45 (+2.0) // zurück in Europe/Berlin : 30 Minuten Unterschied!

Wie an der Ausgabe zu sehen, sind Berechnungen abhängig von der Zeitzone. Die Uhrzeit hat sich gegenüber der Ausgangszeit in Europe/Berlin verändert, da die Sommerzeitgrenze genau in die Periode der zwei Wochen fiel. Bei zeitzonenübergreifende Terminserien kann sich demnach die lokale Uhrzeit ändern! In meinen Anwendungen ist eine Terminserie daher immer an die Ortszeit des Terminorganisators gebunden. Die Zeiten für Teilnehmer in anderen Zeitzonen ändern sich daher manchmal. Alternativ könnten die Termine auch an die UTC gebunden werden. Benutzer kommen damit – meiner Erfahrung nach – aber damit nicht so klar, da sich die Uhrzeit auch dann ändern kann, selbst wenn alle Teilnehmer in derselben Zeitzone sind.

Und MySQL?

MySQL bietet auch einige Zeitfunktionen, meine Empfehlung aber: berechnet alles in PHP. MySQL bietet zwar auch Optionen zur Umrechnung und Berechnung, ihr erspart euch aber, die kleinen Unterschiede zwischen PHP & MySQL zu kennen und damit eine weitere Fehlerquelle. MySQL rechnet intern übrigens nur mit UTC-Zeitstempeln.

Für die Ortszeit muss in der Datenbank neben dem üblichen TIMESTAMP- oder DATETIME-Feld auch eine eigene Spalte für die Kennung der Zeitzone angelegt werden. Nur den Offset zu speichern ist zu wenig, da sich der verändern kann (Sommerzeit!) bzw. unterschiedliche Zeitzonen teilweise denselben Offset haben. Nur mit der Kennung der Zeitzone hat man alle notwendigen Informationen für die Ortszeit. Für SQL-Abfragen arbeite ich in der Datenbank meist noch mit einem zusätzlichen UTC-Feld. Die SQL-Abfrage formuliere ich unscharf (Grenzen um 2-3 Stunden erweitert), die Detailauswertung erfolgt dann in PHP, zugeschnitten auf die Zeitzone des Benutzers.

Fazit

Wäre die Erde eine Scheibe, würde vieles einfacher sein. Die Sommerzeit hätte man sich dann wahrscheinlich auch gespart. So bleibt einem nur, sich mit den vielen Veränderungen und Aufteilungen der Zeit anzufreunden und die für den Anwendungsfall sinnvollste Zeitart zu wählen. Eine einfache Daumenregel: Log-Daten und absolute Intervalle in UTC, alle benutzerbezogen Zeiten in deren Ortszeit speichern. Damit kommt man im Regelfall durch. Das frei verfügbare PDF-Beispielkapitel „Zeit und Zeitzonen“ meines neuen Buches Von Geodaten bis NoSQL: Leistungsstarke PHP-Anwendungen handelt von Zeitzonen. Da könnt ihr noch ein wenig mehr nachlesen.