[TYPO3-dev] Datetime bug in 4.2 - SOLUTION

[Michael Stucki]

Hi Dmitry,

please get in touch with Ernesto Baschny as this changes was made by him.
I'm sure he did proper testing and can tell you why it got broken, and how
it can be fixed.

- michael

Dmitry Dulepov [typo3] wrote:

> Hi!
> 
> The issue is very serious. All time handling is broken. It affects all FE
> extensions that have date/time/datetime values in forms and also any
> content element with starttime/endtime settings. These settings do not
> work properly at all. Never in 4.2. Read on...
> 
> Dmitry Dulepov [typo3] wrote:
>> Anyone has objections about removing timezone handling from TYPO3
>> JS&tceforms (see the patch)? I do not send this as RFC to core list yet
>> because I am not sure while all this UTC handling was added in 4.2. But
>> it obviously does not work properly: editor sets value to 22:35 today
>> and after saving it becomes 1:35 tomorrow. Oops...
> 
> And I finally understood the whole sequence and bugs in the
> implementation: 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). Absolute crap. 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 :)
> 
> I think we should get rid of this UTC conversions. They obviously do not
> work. If you wonder if we can solve it by removing date('O') code in
> TCEforms, the answer is "no" because wrong value will still get to to the
> database. In will not increase by timezone offset on each save but it
> still will be some time ahead.
> 
> By the way, this "date('O')/100" does not work with "half" timezones (like
> "+0130"). So in any case this has to be fixed.
> 
> I will post a patch to remove all this UTC business from 4.2 ASAP.
> 

-- 
Use a newsreader! Check out
http://typo3.org/community/mailing-lists/use-a-news-reader/