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

[Martin Kutschker]

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