[TYPO3-core] RFC #7626: Date/time handling is completely broken in 4.2

[Ernesto Baschny [cron IT]]

Hi,

I am really sorry for causing that much trouble and taking your time in 
debugging and trying out solutions. I haven't had that much time lately 
to follow the discussion.

For most embarassement I have discovered a little snipped of patch that 
was meant for inclusion in that release of my bug fix in october 2007. 
As it looks like this is "it", and considering that everything works on 
my test machine where this patch was developed, I ask you to please 
consider trying it out and see if that solves the problem without any 
other changes needed.

When trying to figure out what "I have meant" when doing this or that 
change in the fix for bug#1697, here is the short summary:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Solution:
The date on server is currently stored as a unixtime based on the server
local timezone. This requires no conversion of timezones if, server,
backend, frontend user are in the same timezone. To keep existing
extensions working we also have make sure that server + frontend output
is not being changed, which means we have to keep saving unixtime based
on server-timezone in the database.

The solution from the patch uses the UTC date as a timestamp transport
standard between the server and the backend-client and vice-versa. The
server will print out HTML and JS with a UTC-unixtime for the date in
the database (class.t3lib_tceforms.php). The client will work with that
UTC time and return UTC-time (all javascript based,
jsfunc.evalfield.js). The server will then translate that back to server
timezone and store it to the database (class.t3lib_tcemain.php).
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

The full blown explanation on EVERY line of my patch from that time:

http://lists.netfielders.de/pipermail/typo3-team-core/2007-May/008157.html

Cheers,
Ernesto

Dmitry Dulepov [typo3] wrote: on 22.02.2008 15:03:
> Hi!
> 
> This is an urgent SVN patch request (must get into beta2!).
> 
> Type: blocking bug
> 
> Branch: 4.2
> 
> BT reference: http://bugs.typo3.org/view.php?id=7626
> 
> Problem #1: Entering date and/or time into the BE form results in wrong 
> date going into database. Value is always incremented by user's timezone 
> offset. When it is loaded next time, value is incremeneted by server's 
> timezone offset and it will be shown even more in the future. Saving it 
> adds more offset to the future. This affects all date time fields: 
> extension's defined or starttime/endtime. As a result extensions will 
> show wrong dates in FE (for example, 15:00 if 13:00 is entered in UTC+2 
> zone) and starttime/endtime will trigger 2 hours later then expected.
> 
> Problem #2: date('O')/100 in TCEForms will not work for so called 
> "half-hour" time zones. date('O') will return "+0130" and this is not 
> handled properly.
> 
> Solution: remove all UTC-related handling from core. Masi has different, 
> much more appealing idea of handling UTC/timezone related issues.
> 
> Detailed analysis (copied from "dev" list):
> ================================
> 0. User, who is in UTC+2 time zone, opens new/edit form for the record 
> with datetime field in it. Any startime/endtime will do. Let's use $TIME 
> for indication of current ~local~ time.
> 1. New datetime value is entered or checkbox is checked near datetime 
> control
> 2. jsfunc.tbe_editor.js ~substructs~ the value of "getTimezoneOffset()" 
> from $TIME and stores result in hidden form field. Value of 
> "getTimezoneOffset()" is "-2h" for UTC+2. Due to substruction we now 
> have $TIME+2h in the hidden form now. It is important, so I repeat: we 
> have local time + 2h in the hidden form field. This is time in future. 
> Wonder why this is done? Read on.
> 3. User leaves datetime input control. Now jsfunc.evalfield.ls is 
> called. It takes value from step 2 ($TIME+2h) and uses getUTC* functions 
> to get... yes, $TIME. I repeat: it uses getUTC* functions but gets local 
> time, not UTC (due to step 2).
> 4. Value calculated at step 3 is set back to control. So visible control 
> shows proper local time. Hidden control still keeps value of future time 
> ($TIME+2h).
> 5. User saves the form
> 6. Wrong value of $TIME+2 gets into the database.
> 7. Form loads again
> 8. t3lib/class.t3lib_tceforms.php adds date('O')/100 to the date value 
> from database ($TIME+2h in the datbase). Now this value becomes localtime+4
> 9. form loads, go to step 2. If you did not realize it yet, time value 
> in the form is $TIME+2h and value in the hidden field is $time+4h now. 
> What happens if save form again? You are right if you think that time 
> value jumps teo hours ahead. Save it 12 times and you are in the next day
> ================================
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug-1697-missing-patch.diff
Type: text/x-diff
Size: 669 bytes
Desc: not available
Url : http://lists.netfielders.de/pipermail/typo3-team-core/attachments/20080225/0a13b4d5/attachment.diff