© saicle/Shutterstock.com
Zeitzonenunterstützung mit Zend_Date und MySQL

Mittag in San Francisco, Abend in London


Bei wie vielen Projekten haben wir bereits Best Practices im Bereich I18N angewendet? Übersetzungen sind leicht, Zahlenformate ebenfalls. Bei Text-Encoding und Zeitzonen wird es schon etwas kniffliger. Gerade bei Letzterem lohnt sich allerdings ein genaueres Hinschauen: Applikationsdaten, die über Zeitangaben verfügen, können relativ leicht flexibel gehalten werden, was für den internationalen Einsatz der Software extrem wichtig ist. Wie Zeitzonenunterstützung realisiert werden kann, zeigt dieser Artikel.

Weshalb sollte man überhaupt eine Software so schreiben, dass sie verschiedene Zeitzonen unterstützt, wenn Entitäten über Datumsinformationen verfügen, die doch sowieso fix in die Datenbank geschrieben werden? Stellen wir uns vor, wir sind ein in London ansässiger Freelancer, der PHP-Entwicklung anbietet. Einer unserer Kunden ist dieses große Maschinenbauunternehmen, für das wir vor Kurzem eine Dokumentenverwaltung geschrieben haben, die intern von der Finanzabteilung eingesetzt wird. Dieses Unternehmen ist im Begriff zu expandieren, und wir feiern bis zur bitteren Sperrstunde den Verkauf weiterer Arbeitsplatzlizenzen mit ein paar Freunden in einer Kneipe. Die Lizenzen sind für das neue Büro in San Francisco vorgesehen, wo das Unternehmen eine neue Außendienststelle gründet. Michael, der vorherige Finanzabteilungschef und einer der Hauptanwender unseres Dokumentenverwaltungstools, wird in den USA das neue Büro beziehen. An einem Nachmittag, zwischen halbvollen Umzugskisten und bei trübem London-Wetter, führt er Tim, seinen Nachfolger, in die Bedienung der Software ein.

Michael, Tim und der 8-Stunden-Unterschied

„Siehst du“, sagt Michael, „sobald du einmal fertig mit dem Dokument bist, klickst du den Teilen-Button und das Dokument landet automatisch in meiner Inbox.“ Er lehnt sich zurück und schnippt mit den Fingern: „So einfach ist das“. Ein paar Tage vergehen. Tim hat sich als Abteilungsleiter eingefunden und mittlerweile sogar einen Benutzeraccount für die Dokumentenverwaltung bekommen, was der Systemadministrator vor einer gefühlten Ewigkeit mit einem Brummen und einem „Wird umgehend erledigt“ angekündigt hatte. Michael richtet sich bereits sein Büro auf der anderen Seite der Weltkugel ein.

Die Software verrichtete in den vergangenen Monaten ihre Arbeit wirklich gut, und jeder ist zufrieden, wie leicht das Teilen und Bearbeiten von Dokumenten von der Hand geht, und wie sehr der Informationsfluss in der Abteilung gestiegen ist. Was keinem bislang aufgefallen ist: Die Software hat Michaels Dokumente und die der Mitarbeiter mit den Zeiten gespeichert, die in der Zeitzone von London gültig sind (GMT), und nun benutzt er die Software in San Francisco. Nachdem er also zum ersten Mal in seinem neuen Büro die Software aufruft, klickt er ein wenig verunsichert durch seinen Arbeitsbereich.

„Komisch ...“, ist sein erster Gedanke. „Diesen Entwurf hier ...“ – er bewegt seinen Kopf näher zum Monitor, während er den Mauszeiger über den Dokumenteneintrag kreisen lässt – „... ich weiß, dass Tim ihn letzten Montag erstellt und mit mir geteilt hat, aber das war ganz sicher nicht um 20 Uhr abends.“ Er kratzt sich am Kopf. „Ich erinnere mich daran, dass ich den Entwurf gegen Mittag bekommen habe... oder war es an einem anderen Tag? Ich war gegen 19 Uhr abends zu Hause, da gibt es keinen Zweifel. Ich kann das Dokument mit Sicherheit nicht zu einem späteren Zeitpunkt bekommen haben. Irgendwas ist hier kaputt. Oder der Stress steigt mir zu Kopf.“

Versuchen wir Michael zu beruhigen. Also, was genau ist hier passiert? Nun, Michael lebt jetzt in einer anderen Zeitzone. San Francisco in Kalifornien gehört zu der PST-Zeitzone, die Uhrzeit richtet sich hier nach der Pacific Standard Time, und liegt acht Stunden hinter der Zeitzone, in der er vorher gelebt hat (sieben Stunden, wenn wir Daylight Saving Time; DST, also Sommerzeit, berücksichtigen).

Während er auf der Suche nach einer Erklärung etwas verloren durch die Software navigiert, fällt ihm genau das auf: Die Applikation berücksichtigt offensichtlich nicht verschiedene Zeitzonen. Wozu auch, bislang hat kein Außendienstmitarbeiter in einem anderen Land als Großbritannien damit gearbeitet. Michael stellt fest, dass die Software auch keine Einstellung bietet, über die man festlegen kann, in welcher Zeitzone man sich gerade befindet. Kein guter Start in Kalifornien. Aber Software wächst nun mal mit den Anforderungen. Und wir möchten doch sicherlich, dass unsere Dokumentenverwaltung auch in Zukunft von einem global expandierenden Unternehmen genutzt wird? Also machen wir uns an die Arbeit.

Unsere Anwendung vorbereiten

Es ist wichtig, dass es in Software Konfigurationsoptionen für die verwendete Zeitzone gibt, sobald Datumsinformationen ein essenzieller Bestandteil der vorgehaltenen Daten sind. Nehmen wir als Beispiel eine beliebige Forensoftware, die dem Anwender eine Einstellung bietet, in welcher Zeitzone er sich gerade befindet. Würde uns diese Forensoftware diesen Mehrwert nicht bieten, würden wir uns nach einiger Zeit wundern, zu welch seltsamen Zeiten manche Internetnutzer noch Forenbeiträge schreiben. Der Code unter der Haube sollte dafür verantwortlich sein, ein und dieselbe Zeitangabe in verschiedenen Zeitzonen korrekt anzuzeigen.

Wenn sie jetzt gerade darüber nachdenken, ob ihre Software von fixen, starren, im Nachhinein nicht mehr korrekt umwandelbaren Zeitangaben betroffen ist, stellen sie sich folgende Frage: Sind Zeitangaben Teil irgendeiner Entität, die dauerhaft in der Datenbank gespeichert werden muss, und haben sie bislang konsequenterweise der Datenhaltung die Information vorenthalten, in welcher Zeitzone das Datum erstellt wurde? Wenn sie hier schon mit einem „Ja!“ einfallen (oder wenn ihr erster Gedanke ein reflektierendes „Ach, verdammt...“ war) muss ich sie enttäuschen: Sie sind so oder so zum Weiterlesen verdammt. Höchstwahrscheinlich nämlich spielt ihre Software mit den Gefühlen der Anwender, sobald sich die Zeitzone ändert – egal, ob es sich um die Zeitzone der genutzten PHP-Umgebung oder der des Anwenders handelt, in der er sich gerade (oder gerade nicht) befindet.

Es gibt nun einige grundlegende und einfache Schritte, die beachtet werden sollten, wenn Zeitzonenunterstützung implementiert werden soll. Und jeder einzelne dieser Schritte sollte umgesetzt werden:

  • Eine globale Standard-Zeitzonen-Einstellung konfigurierbar machen

  • Eine Standardzeitzone definieren und dem Anwender die Möglichkeit geben, seine gewünschte Zeitzone selbst auszuwählen

  • Die (vom Anwender gewählte) Zeitzone bei jedem Request berücksichtigen

Die Zeitzone global konfigurierbar machen

Die Zeitzone sollte in unseren selbstgeschriebenen PHP Scripts global konfigurierbar sein, ohne dass wir auch nur einen einzigen Gedanken an die internen Einstellungen unseres Servers oder der von PHP verschwenden müssen. Glücklicherweise bieten genug PHP-Frameworks unterstützende Komponenten an, wenn es um Konfigurationen von Applikationen geht, und wir bedienen uns der Einfachheit halber der des Zend Frameworks, da wir später sowieso auf Zend_Date zurückgreifen: Zend_Config [1] wird uns helfen, unsere Software parametrisierbar zu halten. Es gibt bereits viele gute Tutorials über die Verwendung von Zend_Config, weshalb wir uns hier auf das Wesentliche beschränken wollen (Listing 1): In einer ini-Datei definieren wir also eine Standardzeitzone. Diese Information soll uns nach dem Auslesen der Konfiguration zur Verfügung stehen:

Listing 1

[environment] ; Zeitzone definieren und dem Konfigurationsparameter zuweisen ; unter http://de.php.net/manual/en/timezones.php gibt es eine Liste ; aller von PHP unterstützten Zeitzonen date.timezone.default = Europe/Berlin
// ini laden $config = new Zend_Config_Ini('/path/to/config/file'); // Standard-Zeitzone auslesen $timezone = $config->environment->date->timezone->default;

So können wir nun recht einfach und flexibel einen Standardwert für die Zeitzone festlegen und jederzeit ändern, ohne mit php.ini-Einstellungen oder PHP-Code experimentieren zu müssen. Das ist der erste Schritt, um mehr Unabhängigkeit von der Vorkonfiguration unserer PHP-Installation zu erlangen und uns von den Fesseln übereifriger Systemadministratoren zu befreien.

Den User eine Zeitzone wählen lassen

Wie können wir nun einem angemeldeten Nutzer unserer Software eine...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang