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

[Steffen Kamper]

"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?

So storing UTC is the first important step to be able to show it in differnt 
TZ's - this does the patch.
Also remember that there is a Conf-Var, that was never used: 
$TYPO3_CONF_VARS['SYS']['serverTimeZone']
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.
Maybe it could help, if Servers TZ is displayed anywhere, so anyone knows 
which timezone is displayed (maybe a switch to users TZ?)

vg  Steffen