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

[Ernesto Baschny [cron IT]]

Martin Kutschker wrote: on 23.10.2007 13:11:

>>> As we don't store any TZ information in date / datetime fields (they are
>>> integers), you should always see 18h00 on any view (list view, backend
>>> form, etc).
>>
>> ok, this is the case now.
>>
>> I just don't know whether this would be right. As if I say 18:00
>> Chicago time I also mean 24:00 CEST - at least in my understanding ...
>>
>> can you explain why this is/should be the right behavior?
> 
> I argue that TYPO3 should store times in the server time zone (or UTC),
> but should display the time in the time zone of the client. This means
> that if I enter a time in my local time, TYPO3 will still show me my
> local time.
> 
> The other option for a consistent UI is to use alywys the server time
> zone for both entering and displaying a time. But this means that the
> editor has to know what the server's time zone is. I think this is maybe
> a bit awkward, but could make sense for some installations.
> 
> For both solution there will be no changing of times for the editor.
> Whatever she enters will stay as it is entered (unless you change the
> local time zone in the former case). If it does, it is a bug.
> 
> So, I think the former should be default, but the latter configurable
> via TYPO3_CONF_VAR.
> 
> Masi

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)

b) we have an API to make use of that in FE-applications.

As we don't store or give the user any chance to define the timezone
information with a datetime he is entering, it is even more confusing if
every user sees different times for the same record. The user must be
aware of where he is, where the server is, and which timezone offset the
server is configured to use for FE-output, so that he can calculate the
date and times he has to enter to generate a certain output in the FE.
This is annoying! The user just wants to enter a date which will be
displaying "as is" in the FE (and of course also in the BE)!

The more agravating problem is not datetime fields, but you will still
have to handle the time and date fields differently. Because if I am
UTC+2 and store "2:00" in a time field, I don't think that I expect that
to be displayed "0:00" when I am in UTC+0 or even -2:00 when I am in UTC-2.

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.

Cheers,
Ernesto