Project

General

Profile

Actions

Bug #18278

closed

Date/time handling is completely broken in 4.2

Added by Dmitry Dulepov about 16 years ago. Updated almost 14 years ago.

Status:
Closed
Priority:
Must have
Category:
-
Target version:
-
Start date:
2008-02-22
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.2
PHP Version:
5.2
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

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.

The solution is to remove new code that appeared in 4.2.

Here is what was found during investigation (copied from http://support.typo3.org/index.php?id=17&tx_nntpreader_pi1[nid]=2&tx_nntpreader_pi1[mid]=326796&cHash=44acdb9066 ):
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
(issue imported from #M7626)


Files

proper-time.diff (5.26 KB) proper-time.diff Administrator Admin, 2008-02-22 14:52
time_bug_fix_7626_v2.diff (3.68 KB) time_bug_fix_7626_v2.diff Administrator Admin, 2008-02-24 15:56
time_bug_fix_7626_v3.diff (4.08 KB) time_bug_fix_7626_v3.diff Administrator Admin, 2008-02-24 23:52

Related issues 3 (0 open3 closed)

Related to TYPO3 Core - Bug #17803: Time fields with strange behaviour in Opera 9.50bClosed2007-11-18

Actions
Related to TYPO3 Core - Bug #65976: TCA: time/timesec fields do not take timezone offset into accountClosed2015-03-24

Actions
Has duplicate TYPO3 Core - Bug #18110: Saving datetime fields in TCEforms changes the date to [day+1]ClosedOliver Hader2008-02-04

Actions
Actions #1

Updated by Steffen Kamper about 16 years ago

My patch converts all times for server timezone, further notes are in core list.

what i did:
  • created a js var that has servers timezone offset
  • on change of datetime field calculated the time of servers timezone
  • removed offset in tceforms
i got fine results with my testing using
  • server UTC +1
  • client UTC +3

entered 17:00
after lost focus calculated to 15:00

For date only values i removed UTC-handling so the date entered is the date that server stores.

Actions #2

Updated by Steffen Kamper about 16 years ago

in the v3 patch i only changed that the js var with the server timezone is printed out in alt_doc.php. So this var is available in all edit forms, also in popups.
Thx Masi for this hint.

Actions #3

Updated by Ingo Renner about 16 years ago

fixed in 4.2beta3

Actions

Also available in: Atom PDF