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

[Ingmar Schlecht]

Hi Dmitry,

most of the code you are removing with your patch is actually reverting 
half of Ernesto's patch #1697 committed to trunk some time during the 
4.2 development phase, and must have unfortunately introduced the bug 
you were experiencing.

We should just revert the first patch completely and then figure out the 
right solution for 4.3; better live with the same old bug all old TYPO3 
versions had than making a risky mix of old and new behaviour now, which 
potentially brings up even more bugs.

cheers
Ingmar


Dmitry Dulepov [typo3] schrieb:
> 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
> ================================
> 


-- 
Ingmar Schlecht
TYPO3 Association Active Member