[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 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)

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.

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.

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

You can avoid that if you show always the date in a specified TZ (be that 
UTC or the servers TZ). The point is that this is also true for entering 
the time. If I (+1 in Vienna) want to enter a date I would need to know 
that the server expects me to enter the time in UTC.

When TYPO3 shows always UTC the time will never change on the client side, 
tough it will be odd for the user. When TYP3 shows the local time (of the 
client), the time will ONLY change if the user changes his TZ, which is 
unlikely unless she travels by plane.

Anyway, both FE and BE may deide to show any time both in local time and 
UTC to clarify this matter for the user.

 > 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 user must only know about offsets if he has to enter a time in UTC.

What is displayed in FE (or BE) is decided by the plugin (or module). a 
plugin may decide to show always times in UTC or in a defined TZ. eg. an 
Austrian site would use +1 by default. An international site could add a 
configuration option to the fe_user record which denotes the preferred TZ. 
Nifty guys could use geo location services via the IP address to find a 
reasonable default for the TZ used for display purposes.

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

Right, pure time fields are different. Whatever TZ you are, the time always 
denotes the offset in regard to midnight. No transformation is allowed here.

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

Masi