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

[Ernesto Baschny [cron IT]]

Hi people,

the fix has been applied, it was the patch attached to this message. 
Major issue was a missing patch for tcemain. Add-on-patch is the 
date('O') fix (using date('Z') now).

Commited to TYPO3_4-2 (rev. 3287).

It would be a candidate for trunk too, but it is "frozen"... right? I 
would have created a branch for TYPO3 4.2 on "release" (and not betaX), 
so that every fix and feature we get until release is also included in 
TYPO3 4.3. Then mark each beta and RC with "tags" (possible in 
subversion, isn't it?). Makes no sense in my eyes for that branch to 
live before we start working on TYPO3 4.3... But ok, too late now, maybe 
on next release.

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-7626-timezonefix.diff
Type: text/x-diff
Size: 2021 bytes
Desc: not available
Url : http://lists.netfielders.de/pipermail/typo3-team-core/attachments/20080225/b9d0e552/attachment-0001.diff