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
_______________________________________________
TYPO3-german mailing list
TYPO3-german@lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german
