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

[Ernesto Baschny [cron IT]]

David Bruchmann schrieb:
> Hi Ernesto,

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

That is not "my practice", that is what TYPO3 core does (for time, date
and datetime fields). So if you use any of these fields, the information
is not GMT time, but in server TZ.

Of course you are free to use other tables which are not handled by
TCA's time/datetime/date eval, but then we are not talking about the "core".

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

I wrote that you store the original date + TZ, but need functions to
display that information in different TZs, and sometimes even more than
one output in a single request. I think you haven't really read what I
wrote. :)

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

Hehe, nice use case. I don't see any reason to have two timestamps for
one particular event. If you have the original TZ information, the rest
can be calculated, just like you wrote.

So we all agree, but my point was that we should do it "right" then
(with PHP's datetime classes that also support dates before 1970)
instead of adding more functionality in our unixtime handling.

Cheers,
Ernesto