Zum Inhalt springen

TYPO3 + Timestamp + Timezone = Rauchender Kopf

Erstellt am 27. Juli 2011 · 2 Antworten · letzte Antwort am 3. August 2011

Tags: TCA, PHP, Frage

rabe69 ·

Hallo Leute,

ich versuche nun schon seit Tagen nachzuvollziehen, wie ein Datum, welches ich über einen Datepicker im Backend auswähle umgewandelt wird und schliesslich in der Datenbank landet.

Meine bisherigen Erkenntnisse:
- Alle Backend-Datumseingaben über den Datepicker nach 1.1.1970 (!) werden als Timestamp in der Zeitzone des Servers unter Berücksichtigung der Sommer/Winterzeit in der Datenbank abgelegt.
Der Javascript Datepicker selbst generiert immer den Timestamp nach UTC und legt diesen zunächst in einem hidden Field ab. TYPO3 wandelt diesen Wert dann scheinbar beim Abspeichern noch einmal um.
- Bei Datumseingaben vor 1.1.1970 wird beim Abspeichern weder Sommer/Winterzeit, noch die Zeitzone berücksichtigt.
- PHP und somit auch der strftime Befehl von Typoscript beziehen beim Umwandeln von Timestamps nach z.B. ISO8601 die Zeitzone des Servers mit ein.
- Im TYPO3 Backend ist es nicht möglich mit dem Datepicker den 1.1.1970 auszuwählen.

Aktuell habe ich das Problem, wenn ich ein so eingegebenes Datum direkt aus der Datenbank als Timestamp auslese (ohne irgendwelche API Befehle zur Konvertierung) und über ein Plugin im Frontend ausgebe und dort über einen Javascript-Befehl in ein Datum umwandle, wird dort nahezu immer ein falsches Datum bzw. Uhrzeit angezeigt.

Das Problem is einerseits, das die Daten beim Abspeichern in TYPO3 mit einem mir nicht nachvollziehbaren Offset versehen werden, welcher beim Auslesen zum dem Fehler führt.
Die Frage ist nun, ob es eine Möglichkeit gibt einen solchen "TYPO3"-Timestamp wieder in einen "richtigen" Timestamp umzuwandeln.
Irgendwo hab ich mal gelesen, man sollte hierfür einen stdWrap nutzen.

Wie könnte so etwas denn aussehen?

Oder hat jemand noch eine ganz andere Lösung/Idee wie man das Problem in den Griff kriegen kann?

Bitte Helfen - ich dreh sonst noch durch 😢

Unbekannter Benutzer ·

Hi,

Wie wäre es wenn du erst mal genau erklärst, was denn genau dein Ziel/Aufgabe ist? Das konnte ich aus deinem Beitrag nicht rauslesen.

Hast du eine eigene Extension geschrieben, in der das Datum falsch gespeichert/ausgegeben wird oder redest du von einem TYPO3-internen "Problem"?

rabe69 ·

Hallo Typo3Cuckoo,

wie die Rubrik in der ich diese Frage vielleicht schon vermuten lässt, handelt es sich um eine eigene Extension um die es sich in diesem Post dreht, genauer gesagt Powermail.

Ich konnte das Problem aber mittlerweile lösen.

Falls jemanden interessiert:

Der Datepicker von TYPO3, welcher erscheint wenn man in einer Flexform-Definition den Eval-Typ "date" oder "datetime" angibt, generiert, nachdem man ein Datum ausgewählt hat (oder man die Zeit dazu verändert), einen Timestamp der zunächst in einem versteckten Formularfeld abgelegt wird. Dieser Zeitstempel geht immer von der GMT bzw. UTC Zeit aus.

Wenn man allerdings auf "Speichern" klickt, wird ein anderer Timestamp in die Datenbank geschrieben, der von der Zeitzone des Servers abhängig verschoben ist. Hier spielen dann auch noch Sommer und Winterzeit (sofern vorhanden) des eingestellten Datums eine Rolle.
Bei Datumseingaben vor 1.1.1970 entfällt diese Verschiebung allerdings, sodass der Wert aus dem versteckten Feld beim speichern direkt in der Datenbank landet.

Bei der Ausgabe ist es dann ähnlich. Hier wird der Zeitstempel, wenn man ihn über Typoscript formatiert ausgibt, wieder ausgehend von der Zeitzone des Servers zurück verschoben.
Das hat mir aber nichts genützt, da ich diese Wert direkt aus der Datenbank auslese.
Um dennoch den "richtigen" Zeitstempel für meine Frontendausgabe zu kriegen, habe ich ihn zunächst mit folgender Lösung auf GMT bzw. UTC Zeit gebracht:

if($value > 0) {
	$value = gmmktime(date("H", $value), date("i", $value), date("s", $value), date("m", $value), date("d", $value), date("Y", $value));
}

Zusätzlich hatte ich das Problem, das ich auf Client-Seite auch einen Datepicker ausgebe, der mit dem zuvor im Backend ausgewählten Datum voreingestellte sein sollte.
Hier spielte mir dann auch noch die Zeitverschiebungsberechnung des Clients mit rein, die in Javascript von jedem Browser unterschiedlich gehandhabt wird.
Diese Problem konnte ich dann durch Änderungen im Javascript lösen (getUTCHours() statt getHours() etc.).

Damit mir TYPO3 dann auf der Bestätigungsseite und Email, die so gewonnenen Daten richtig anzeigt (die Formatierung läuft über den Typoscript-Befehl "strftime"), musste ich noch einen mir bisher unbekannten Typoscript-Befehl einsetzen:

strftime.GMT = 1