[TYPO3-core] RFC #8522: Bug: Datetime shifts on copy and localize (timezone related)

[lee perry]

Hi Ernesto,

thanx for the good work - it works!

+1 by reading and testing

(maybe a little bit to late, but I didn't know about the "+1" thing)

greetings,
Lee

> Hi,
> 
> thanks for the support. Committed to TYPO3_4-2 (rev.3735) and trunk 
> (rev.3736).
> 
> Cheers,
> Ernesto
> 
> Ernesto Baschny [cron IT] wrote: on 27.05.2008 11:27:
>> This is an SVN patch request.
>>
>> Type: Bugfix
>>
>> Bugtracker references:
>> http://bugs.typo3.org/view.php?id=8522
>>
>> Branches:
>> trunk and TYPO3-4_2
>>
>> Problem:
>> Input-Fields with eval "date" or "datetime" will get its value shift 
>> by "server-timezone" minus "UTC" when copying the record or localizing 
>> the record.
>>
>> How to reproduce:
>> Install the "user_datetest" extension attached to the bug report. This 
>> will just create a new table with all possible datetime fields 
>> avaliable to test and also make them localizable. Follow the steps:
>>
>> 0) make sure your server is not running on UTC, else the bug will not 
>> show up. Any "german server" should be ok (UTC+2 currently).
>> 1) create a "Date Tests" record, tick every checkbox to get current 
>> date and times in all fields.
>> 2) save the record.
>> 3) copy the record (e.g. using the clipboard): Result without the 
>> patch are shifted datetimes.
>> 4) localize the record to another language: Result without the patch 
>> are shifted datetimes in the localized record.
>> 5) now apply the patch.
>> 6) repeat steps 3) and 4), watch the results.
>> 7) come back to the list give a +1.
>>
>> Solution:
>> Attached patch. Thanks to lee perry for the original bug report.
>>
>> Notes:
>> The problem comes from the fact that TCEmain "checkValue" 
>> transformations were being applied on already transformed data (from 
>> the database) even in case of a copy (which is also used on 
>> "localize"). Until now there was no problem, because all checkValue 
>> transformation would do no harm on already transformed input (e.g. 
>> trim on trimmed string does nothing, "upper" on already upper cased 
>> string is harmless, etc), but it turned out to be a problem on the 
>> transformation needed for datetime fields (shifting the INPUT coming 
>> from the client, which is expected as UTC to server-TZ timestamp).
>>
>> So the solution is not to apply any checkValue in case of COPY or 
>> LOCALIZE (which uses COPY), which is what the patch does.
>>
>>
>> Cheers,
>> Ernesto
>>