[TYPO3-german] Fluid <f:format.date> addiert 1 Stunde

[bernd wilke]

Am 09.01.15 um 08:57 schrieb Marc Willmann:
> Hallo Renzo,
>
>
> Am 08.01.15 13:10, schrieb Renzo Bauen:
>
>> Sowas funktioniert zwar ist aber alles andere als elegant.
>> Wie man googeln kann, funktioniert die Anzeige mit dem Viewhelper
>> f:format.date eigentlich sehr gut. Aber wenn ich das nicht die UTC
>> Formatierung nehme, sondern z.B. d.m.Y dann kann ich nie mehr einen
>> Datumswert speichern. Denn der Validator von Extbase akzeptiert
>> ausschliesslich das UTC Format.
>
> Ich vermute, Du meinst das richtige, aber der Vollständigkeit halber:
> UTC ist keine Formatierung, sondern eine Zeitzone (koordinierte
> Weltzeit, identisch mit GMT).
>
> Unix-Timestamps sind was anderes; die zählen die Sekunden vom 01.01.1970
> 0:00 Uhr.

jein. Im Prinzip hast du schon recht, was Marc aber wohl meinte: beim 
Abspeichern als UNIX-Timestamp wird eien Zeitangabe in die UTC-Zeitzone 
umgerechnet.

>> Für den Deutschen Sprachraum funktioniert das nicht, denn ich kann den
>> Leuten nicht zumuten ein Datum in der Form 2015-01-08T00:00:00+01:00
>> einzugeben! Es muss möglich sein 8.1.2015 als gültiges Datum zu
>> akzeptieren, ohne Zeit und ohne strickte Formatvorgaben. Und dafür gibt
>> es eben keine einfache Lösung...!
>
> Ich kann Dir nicht folgen; ich habe mehrere TYPO3-Installationen am
> Start, wo die Redakteure das Datum genau so eingeben. In der Datenbank
> landen UNIX-Timestamps, die per TS oder Fluid so konfiguriert werden,
> wie ich sie im jeweiligen Template eben brauche.

hier scheinst du entweder eine sauberere Konfiguration, oder einfach 
Glück bzgl. der konfigurierten Zeitzonen zu haben.

es gibt schon Konfigurationen wo je nach Situation eine Zeitangabe 
scheinbar um Stunden springt, weil bei der ganzen Umrechnerei zwischen 
UTC und aktuell benutzter Zeitzone (Eingabe, Ausgabe, Viewhelper, ...) 
alles komplizierter gemacht wird als es benötigt wird (und z.B. 
fehlerhafterweise bei jedem Bearbeiten ein Offset addiert wird).

Gerade wenn man nur ein Datum benötigt (und benutzen will) und die 
Uhrzeit dann auf 0:00 gesetzt wird kann eine Änderung um eine Stunde auf 
einmal im vorherigen Tag landen.
Auch der Ausweg die Uhrzeit dann auf 12:00 zu setzen funktioniert nur 
bedingt: testet man zwei Datumsangaben kann die Uhrzeit immer noch 
differieren und ein gleiches Datum auf einmal ungleich sein.

> Oder sprichst Du von der Eingabe des Datums im Frontend? Das ist eher
> ein spezieller Fall, der nicht so häufig vorkommt - über Datepicker (die
> dann Timestamps übergeben) oder analog der Antwort von Philipp Gampe
> lässt sich das aber auch problemlos lösen...

egal ob BE oder FE: wenn man es sich genau überlegt braucht es einiges 
an Zusatzkonfiguration um ein Verhalten genauer festzulegen.
betrachten wir mal drei Standort: Japan, Deutschland, New-York / Editor, 
Server, Besucher (beliebig zuordnen bar)

jetzt heißt es: eine Information soll ab 20:00 angezeigt werden.
20:00 Japan, 20:00 Deutschland oder 20:00 New York?
die Zeitzone des Editors oder die des Servers oder die des Seitenbesuchers?
Wenn der Editor eine solche Zeitangabe einträgt soll seine Zeitangabe 
dann aus seiner Zeitzone auf Serverzeitzone (oder Besucherzeitzone) 
umgerechnet werden oder unverändert übernommen werden (um dann bei der 
Auswertung erst interpretiert werden)?

für jede Möglichkeit gibt es Anwendungsfälle und somit kann es (ohne 
nähere Spezifikation) keine allgemeingültige, widerspruchsfreie 
Verhaltensweise geben. vermutlich funktioniert alles zu 95% weil die 
Zeitzonen alle identisch sind und jede 'Umrechnung' zur gleichen Uhrzeit 
führt. Ist ein Rechner aber aus irgendeinem Grunde auf einmal in einer 
anderen Zeitzone scheint alles nur noch zu spinnen.

da wir in TYPO3 keine solche Zusatzkonfiguration haben wird es immer 
wieder mal zu Installationen mit unerwünschtem Verhalten kommen.

bernd
-- 
http://www.pi-phi.de/cheatsheet.html