[TYPO3-core] RFC: Bug #1697: Datetime input fields and timezone shift bug

[Steffen Kamper]

"Martin Kutschker" <martin.kutschker-n0spam at no5pam-blackbox.net> schrieb im 
Newsbeitrag 
news:mailman.1.1193171516.14266.typo3-team-core at lists.netfielders.de...
> Ernesto Baschny [cron IT] schrieb:
>> Martin Kutschker wrote: on 23.10.2007 15:53:
>>
>>>> I might agree that we can have this enhancement as soon as:
>>>>
>>>> a) we have an interface for storing and retrieving timezone of the
>>>> client on the server (currently we only have this information on the
>>>> client in javascript)
>>> The server doesn't need to know the client's TZ as long as the client
>>> knows the one of the server. I mean, the client could transform the
>>> entered local time into server time on submit. Which works fine in BE,
>>> but could be a problem in FE. But in FE you will always have these kind
>>> of problems when for some reasons no JS is available.
>>
>> The submital is not the problem, but View>List, which is not rendered
>> with JavaScript. How should TYPO3 know which time to display in the
>> backend if the server doesn't know the clients TZ?
>
> Ah, here's the bugger.
>
> Solution for BE: the login mask or some other loader script sends via JS 
> the TZ of the client, which is then stored in the session.
>
> Alternate/additional solution: the BE has an option (user TS?) to force a 
> specific TZ for entering/displaying. Maybe someone wants this when only a 
> few users are not in the "main" TZ. OTOH, this could also be forced for 
> some fields, so eg news are always UTC, but log entries etc show up in 
> local time, etc
>
> Solution for the FE: this is up to the plugin. We provide a basic API for 
> coomon cases. Maybe we include some JS to get the TZ and set it back via 
> AJAX or POST.
>
>>> We should never store TZ in a timestamp. We just need to know whether it
>>> is UTC or server's TZ (defined by TYPO3_CONF_VAR). Easy to manage for BE
>>> and FE code.
>>
>> We always store the datetime based on the servers TZ, as it has always
>> been. My original patch does keep that "unofficial standard" so that no
>> DB update is necessary after applying the patch.
>
> Nice that we agree on that one. Still I think tha we could use this TZ 
> setting for 4.2, but fix display problems in 4.1 using the old way.
>
>> My patch just makes the client transform the date into UTC, send THAT to
>> the server, so that the server can be sure he got a UTC timestamp, which
>> he can then convert back to his server TZ (which he knows).
>
> Fine with me. It's exactly what I want. The other stuff I was talking 
> about is only icing.
>
>>>> More dramatic are dates, where the stored timestamp is a unixtime for
>>>> "midnight" on that day. But depending on the constelation of client /
>>>> server timezones, the date entered and displayed might switch.
>>
>>> True again. But easy to manage as long as we know that we're dealing
>>> with a "date field" and not a "datetime field". If it's a "date field"
>>> we must get the date parts (day, month, year) on the server side using
>>> the server's TZ setting (again the options are real TZ or UTC for
>>> everything) before passing them to the client.
>>>
>>> All in all, I think everything is quite clear as long as we know that
>>> time, date and datetime fields are not the same and we know that all
>>> datetime fields have to be stored in one well-known (ie configured) TZ.
>>
>> It might be clear, but what is unclear to me is who will solve that and
>> how?
>
> The one who has time to do? Anyway, what is left to fix once your patch is 
> in?
>
> Will time fields still be affected by TZ settings? I think that one 
> shouldn't be so hard to fix.
>
> Thinking again about the date fields I guess they are as good as they can 
> get after your fix. It's only the rendering code that must take the 
> server's TZ into account.
>
> Masi

I smell some good enhancements :-)

So lately a +1 for Ernesto's patch
and a lot of ideas for the following enhancements.

I fully agree with Masi's idea to do the framework in 4.1.x and use it in 
4.2. All the issues could be spread in different patches / RFCs with 
relation to this one.

vg  Steffen