[TYPO3-core] RFC: #12229: stdWrap has date but no gmdate

[David Bruchmann]

Hi Ernesto,

>>>
>>>> What about real timezones instead of just an hour offset?
>>>> 10.strftime= %a %H:%i
>>>> 10.strftime.gm = 1
>>>> 10.strftime.gm.timezone = CET
>>>>
>>> Yes that's a good idea but when gm stands for GMT than it has to be
>>> renamed becaus it doesn't make any sense in this context.
>>> I'd omit it and take only these lines:
>>>
>>> 10.strftime= %a %H:%i
>>> 10.strftime.timezone = CET
>> Yep (see my other posting).
>>
>> But the original patch only wanted a switch to use gmdate() and gmstrftime() instead of date() and
>> strftime(). Storing timestamps in the DB as GM makes sense and is quite usual.
> 
> Not in TYPO3 for now. We store (for backwards compatibility reasons) in
> servers timezone, and only convert to/from UTC when transfering the
> datetime from client to server and vice-versa.

Ok, that is your practice. But the szenario with a company in different 
countries shows that it can be useful to have always the same basetime.

> 
>> What are your use cases for TZ support in stdWrap date/strftime? Why don't you apply the offset
>> somewhere else? Do you have any plans how the could should actually work (parsing TZ name etc)?
> 
> Agreed for the "simple" usage of gmstrftime for now. So am also for the
> "easy" .gm=1 property.
> 
> A valid scenario for more complex "TZ-offsets" is a site listing
> something like formula-1 events: those always have a "local time" but
> also a "user time": The local time is the one stored with the entry in
> the DB, the user time depends on where the user is located: and we might
> need both times to be displayed to the user (so that he knows when to
> turn on the TV) (e.g. [2]).

Those data haven't to be stored because they can be calculated.
Storing two timestamps is redundant. You have to store one timestamp and 
the visitors timezone, the rest is calculation - and a timezone (or 
+/-X) is smaller in the Database.
The only szenario where storing of two timestamps could make sense is 
really when you want to store a timestamp that can't be recalculated. As 
far as I see it's only the case when you want to store the sunset of a 
special region behind a mountain or something like that.

Best Regards
David