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

[Marc Willmann]

Hallo Bernd,

>>> 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.

DAS sollte natürlich auf keinen Fall passieren; aus diesem Grund ist es
ja auch exterm wichtig, dass die Serverzeit in einer definierten
Zeitzone (UTC) geführt wird. Und zwar unabhängig davon, ob der Server in
UTC steht (tut er bei mir meist nicht) oder nicht.

Ein beliebter Fehler ist es, dem Server die Ortszeit einzugeben; korrekt
ist aber UTC und zusätzliche die Zeitzone zu pflegen. Auf den ersten
Blick macht das keinen Unterschied, aber genau für Dein
Anwendungsszenario ist das schon relevant.

> 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.

Ja, das ist auch dirty. Vor allem verkompliziert man damit seine
Datenbankabfragen, weil Du dann immer eine Datumsrange abfragen musst.

> 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?

20:00 Uhr in der Zeitzone des Servers. Über alles andere kann der Server
keine Entscheidungen treffen. Sollte der Editor in einer anderen
Zeitzone sitzen, müsste er tatsächlich umrechnen - BEIM Eintragen der
Zeit. Das ist aber unabhängig von TYPO3 oder auch nur des Internets;
wenn ich nach Mexiko telefoniere, muss ich mir auch überlegen, wie spät
es dort ist, um nicht alle aus dem Bett zu holen... ;-)

> 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)?

Das ist eine Frage des Workflows; pflegen regelmäßig nur Redakteure in
nur EINER Zeitzone einen Server in einer anderen Zone, könnte man den
Offset natürlich automatisch berechnen. Das ist bei mir tatsächlich aber
selten der Use-Case; wichtig ist eben, dass der Server die Zeit in UTC
in die Datenbank ablegt und beim Ausgeben der Zeit in die korrekte
Zeitzone umrechnet. Damit habe ich bislang wenig bis keine Probleme gehabt.

Probleme gab's regelmäßig nur dann, wenn Server auf Lokalzeit
konfiguriert waren und dann auf Datum 0:00 geprüft wurde (die
gespeicherte Zeit aber 23:00 oder 01:00 war).

Marc


-- 
Marc Willmann. TYPO3-Freelancer.
http://www.marc-willmann.de

Seelandstr. 14-16
D-23569 Lübeck

TYPO3 Certified Integrator