Bug #20088


In BE time and datetime fields GMT-0 will be shown by javascript, but GMT+1 will be saved

Added by Sonja Schubert about 15 years ago. Updated over 12 years ago.

Should have
Target version:
Start date:
Due date:
% Done:


Estimated time:
TYPO3 Version:
PHP Version:
Is Regression:
Sprint Focus:


When you choose 9 am in TCA time and datetime fields, 9 am will be shown in the field as value, but the timestamp for 10 am will be saved in the record.

So GMT-0 will be shown and GMT+1 (or what isset on server) will be saved.

This problem occurs in all TCA time and datetime fields in TYPO3 backend of Version 4.2.6. I have tested this also on TYPO3 4.2.3. On TYPO3 4.1.5 the problem does not exist.

This bug is very confusing for the editor so it would be nice when it could be fixed soon.

(issue imported from #M10534)


10534.diff (1.13 KB) 10534.diff Administrator Admin, 2010-06-17 16:55

Related issues 3 (1 open2 closed)

Related to TYPO3 Core - Bug #19855: datetime evaluation again buggy in TYPO3 4.2.4-devClosedErnesto Baschny2009-01-19

Related to TYPO3 Core - Bug #22918: Record time is shown incorrectly in the backend due to DST (-1h)Closed2010-06-17

Related to TYPO3 Core - Feature #61110: Support for timezones in all date fields in TYPO3 BENew2014-08-21

Actions #1

Updated by Ernesto Baschny about 15 years ago

Sonja, please re-check.

This bug was fixed in 4.2.4. So 4.2.3 is of course buggy, but 4.2.6 should be ok.

Make sure you clear all your browser's cache and also that your proxy isn't caching the javascript files anymore (shift-reload the backend a couple of times).

If the problem still persists, please give us a detailed example on how to reproduce, meaning information like:

- operating system, browser/version and timezone your client is on
- whether you are creating a new record, updating an existing one,
- which date do you enter in the field. Or if you tick the "current" checkbox,

So that we have a single way to reproduce the problem if we follow your step-by-step instructions.

Actions #2

Updated by Sonja Schubert about 15 years ago

Thank you for your answer.

I have rechecked it again after deleting all browser caches.

The problem occurs still always in the following way:
Field in my own extension with the following TCA config
"config" => Array (
"type" => "input",
"size" => "5",
"max" => "20",
"eval" => "time",
"checkbox" => "0",
"default" => "0"
Existing record:
In backend I click into the checkbox and change then the time in the input field to 09:00. Wenn i leave the input field the time is changed to 9:00. Now I save the backend form and look into the source code I see the timestamp value for this field is 32400, which is 10:00 in GMT+1. On the website 10:00 is shown, server timezone is GMT+1.

The same problem occurs with TCA eval datetime. I tested it also with tt_news field datetime. There its the same problem.

Needed informations:
TYPO3 4.2.6
Browser Firefox 3 on Mac system(CET, Genf Switzerland time) but also with Firefox 2 on Mac tested

Actions #3

Updated by Marco Antonioli over 14 years ago

I can reproduce on Typo3 4.2.10 (and also 4.2.6)
Firefox 3.5

Actions #4

Updated by Sven Teuber over 13 years ago

The problem still occurs in TYPO3 4.3.7. I don't think it is javascript-related, though, because in the list module, the "show fields" function displays the wrong time, too - as plain text, not in a form field.

Actions #5

Updated by Myroslav Holyak over 13 years ago

You see... When we enter date by hands it's converted to timestamp via JS Date object, ant it takes your local mashine time as base for calculation. And on server we can easly have different time zone. So date in BE and FE could look totally different. It's serious problem when server is located in Germany, and editors are from Canada and Ukraine.

Actions #6

Updated by Ernesto Baschny over 13 years ago

I have read Sonja's comment and we should separate the issues here:

datetime = unixtime at server TZ is stored in DB
time = seconds since midnight is stored in the DB

This means that for a "time" field, the TZ should not play any role at all. The value "32400" = 9h00 because "32400 / 60 / 60 = 9". This is also what the t3lib_befunc::time function returns.

This also means that to display the time in the frontend, you cannot use stdWrap ".date" or ".strftime" but have to use ".strftime.GMT = 1" or ".date.GMT=1" (available since 4.4).

Actions #7

Updated by Myroslav Holyak over 13 years ago

Ok, it clear with time. Especially thanks for gmdate in stdWrap.

What about time? Using JS Date object seems to be bad way due to local machine time dependency. Maybe there is some sense to send plain-text (not timestamp as it is now!) date to server and make conversions with it according to $TYPO3_CONF_VARS['SYS']['serverTimeZone'] ? On client side we can make some js evaluation for general date formating only.

Actions #8

Updated by Ernesto Baschny over 13 years ago

@Myroslav, before we start mixing up matters again: you mean "time" or "datetime"? :)

With "datetime"
1) the client transforms the entered datetime via JS to UTC,
2) this UTC unixtime is transmitted to the server,
3) Server then converts it back to "local time". This conversion is done using the date('Z') (which returns local offset to UTC).

The $TYPO3_CONF_VARS['SYS']['serverTimeZone'] setting is not used anywhere in the TYPO3 core and should be banned, because it causes so many confusion. You should rely on PHP to get the current local timezone or the offset to UTC.

The only reason we store the datetime as a unixtime in server local timezone in the database is for backwards compatibility reasons: It has always been like that and thus we don't change it.

Actions #9

Updated by Myroslav Holyak over 13 years ago

I speak definitely about "datetime". So, @Ernesto, i reproduced that process of datetime saving step-by-step, looking with firebug and phpmyadmin and yes, you are right, and i'm wrong.

Why want you to see $TYPO3_CONF_VARS['SYS']['serverTimeZone'] banned? I know it's not used anywhere (I was lloking in sources), but how else to retrieve = Y-m-d H:m in time zone different from current server?

Actions #10

Updated by Ernesto Baschny over 13 years ago

stdWrap does not use "serverTimeZone".

If we want stdWrap "date" and "strftime" to be able to display an unixtime in different timezones, it should be implemented in a more standard way, using "well known" libraries for DateTime and Timezone handling (e.g. PHP's DateTime) instead of a "serverTimeZone" offset global variable.

Actions #11

Updated by Stefan Galinski over 12 years ago

  • Target version deleted (0)

Can this be closed, Ernesto? The result sounds more than required additional features/cleanups than the initially mentioned bug.

Actions #12

Updated by Ernesto Baschny over 12 years ago

  • Status changed from Needs Feedback to Rejected
  • Complexity set to nightmare

No further action required (for now). A new feature might be interesting to replace the current unixtime based date+time fields, but this is yet another topic.

Also refer to #32081 for a documentation on the mentioned unixtime transformations.


Also available in: Atom PDF