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

[Michael Stucki]

Perfect, thank you very much! So can everybody now confirm that this is
working?

Dmitry? Steffen?

- michael

Ernesto Baschny [cron IT] wrote:

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

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