TYPO3 Core

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,
etc...

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

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

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

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.

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.

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).

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.

@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.

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 stdWrap.date = Y-m-d H:m in time zone different from current server?

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.