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

[Ernesto Baschny [cron IT]]

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? Which is currently
why there is a discrepancy between the datetime the user entered and all
non-js-based output modes in BE (Web>View>, having a datetime label for
a record, etc).

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

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

Exactly, but currently neither the FE nor the BE knows the TZ of the
client (as I explained above), which makes these tasks a job for a
future RFC which adds those enhancements.

The only place that knows the clients TZ is the TCEform which uses
JavaScript to validate and transform the entered date.

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

>> 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? My session during devdays with Mario Matzulla (author of cal and
original brain behind the patch) which resulted in the proposed patch
comes from input and bug reports that many users have already reported.
In my eyes those are solved, because the current behaviour aparently is
not the expected one.

If you install the test extension and try out different date and time
and timezones you will certainly "feel" better what is wrong.

It also has been a long time ago, maybe I should just refresh my view on
that matter. Maybe Mario (cal), Oliver Klee (seminars) or Jeff Segars
(which I think was the affected by that trouble in cal) can bring us
some input here from their point of view.

Cheers,
Ernesto