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

[Martin Kutschker]

Steffen Kamper schrieb:
> "Martin Kutschker" <Martin.Kutschker at n0spam-blackbox.net> schrieb im 
> Newsbeitrag 
> news:mailman.1.1193147605.8874.typo3-team-core at lists.netfielders.de...
>> 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
> 
> This discussion also show how difficult this issue is. At the beginning i 
> thought that it is quite simple - we have UTC and TZ, but all the 
> dependencies and different showcases makes it really complex.
> 
> Another simple example: There is a news item with a start date. Now an 
> editor in US sets the startdate to 10:00 am. What do you expect in germany, 
> when will the news item appear?

As I have said: it depends on what the TYPO3 installation expects from the 
BE user: UTC, server's TZ or client's TZ.

> So storing UTC is the first important step to be able to show it in differnt 
> TZ's - this does the patch.

Not quite right. Important is to use ONE time zone for storing the datetime 
values. As long as you know which it is, you can make any offest 
calculations you want.

Forcing UTC will break current installations. As TYPO3 isn't clever enough 
right now, we must assume that 99% of installation have data in the only 
one TZ, which is the server's TZ.

What we must do is to allow the TZ to be configurable just like charsets. 
For new installations this should be UTC, but an empty value will default 
to the server's TZ (as defined by the OS).

> Also remember that there is a Conf-Var, that was never used: 
> $TYPO3_CONF_VARS['SYS']['serverTimeZone']

Ah, this is excatly what I mean!

> This is a possibility to read the server TZ.
> 
> Next step ist the display - there are several possibilities:
> - show datetime in servers TZ
> - show datetime in users TZ
> - show datetime in entered TZ
> 
> first is simple, second could be done by JS, third is not possible, because 
> this information is never stored.

I think the third one is not important. For the BE options 1 and two could 
be configured via user TS. For the FE any plugin may decide what is 
appropriate. Maybe we can provide an API for typical use cases.

> Maybe it could help, if Servers TZ is displayed anywhere, so anyone knows 
> which timezone is displayed (maybe a switch to users TZ?)

Either that, or as already suggested by me, display both UTC and local 
time. If there are place restrictions we could use the title attribute to 
display the "other" time. By another TS confivuration we could set which 
one is the preferred one.

Masi