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

Dmitry Dulepov [typo3] dmitry at typo3.org
Fri Feb 22 15:03:25 CET 2008


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

-- 
Dmitry Dulepov
TYPO3 core team
Web: http://typo3bloke.net/
Skype: callto:liels_bugs
"Nothing is impossible. There are only limits to our knowledge"
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 7626.diff
Url: http://lists.netfielders.de/pipermail/typo3-team-core/attachments/20080222/ffd3816a/attachment.txt 


More information about the TYPO3-team-core mailing list