[TYPO3-dev] process_datamap() & timestamp

[Ernesto Baschny [cron IT]]

Hi,

Jan Kornblum schrieb am 24.11.2011 13:30:

>> The opposite is the case:
>>
>> Input coming from browser is UTC (browser transforms the client-side
>> input into UTC via JavaScript), which is transformed to server timezone
>> and stored into the DB with server TZ.
> 
> Are you sure that browser transforms it on client-side?

I am pretty sure, because I implemented it some years ago. It could have
been changed again, but I am confident that noone dares to touch this
very bizarre time-handling routines.

> I've tested it
> as follows:
> 
> 1.
> DateTimePicker value in Browser is:
> 16-11-2011

Don't be mislead by what you see "in the browser".

For every input field there is a "hidden" field which is what is later
stored in the database. So the datetime picker field has a "XXX_hr"
field (human readable) which is what you edit and where you input your
date. And there is a related hidden "XXX" field, which is calculated
from the _hr field using javascript. In this case, it will contain the
UNIX timestamp (in UTC):

See t3lib/jsfunc.evalfield.js, find the method
"convertClientTimestampToUTC".

> 2.
> The incoming data array is:
> $this->pObj->submittedData['tx_ext_table'][5]['datefield'] = 1321398000
> ...which also responds to: 16-11-2011

This is UTC time.

> 3.
> The result in DB is:
> 1321394400, which responds to 15-11-2011.

This is in your server timezone.

"1321394400" is a timestamp that has no timezone information attached to
it. So depending on which timezone you are refering to this unix time, a
different date is interpreted:

1321394400 = 2011-11-15 23:00:00 UTC
1321394400 = 2011-11-16 00:00:00 UTC+1 (which is probably your server
timezone, and this is the date that TYPO3 will be working with)

The background of storing server timezone-based instead of storing UTC
based in the database, is "backwards compatibility": We had always
stored the timestamps based on server TZ (and not UTC based).

> So there doesn't seem to take place any transformation on client side.
> 
>> This transformation needs to be disabled if you are just reading the
>> data from database and re-writing it back (no client involved):
>>
>>    $tce = t3lib_div::makeInstance('t3lib_TCEmain');
>>    $tce->stripslashes_values = 0;
>>    $tce->debug = 0;
>>>  $tce->dontProcessTransformations = 1;
>>    $tce->start(array(),$cmdmapArray);
>>    $tce->process_cmdmap();
> 
> O.K., that should work for my case. Thanks!
> 
>> "transformations" in this situation are stuff that TCEmain does on the
>> input that usually comes from the browser (I think *only* RTE and
>> datetime in UTC) and which cannot be reapplied at will (not idempotent).
>> These are disabled on copy / translation / and other internal methods
>> and should probably also be disabled in the situation from Jan.

Cheers,
Ernesto