Bug #20088
closedIn BE time and datetime fields GMT-0 will be shown by javascript, but GMT+1 will be saved
0%
Description
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)
Files
Updated by Ernesto Baschny over 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,
etc...
So that we have a single way to reproduce the problem if we follow your step-by-step instructions.
Updated by Sonja Schubert over 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
Updated by Marco Antonioli over 14 years ago
I can reproduce on Typo3 4.2.10 (and also 4.2.6)
Firefox 3.5
Updated by Sven Teuber almost 14 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.
Updated by Myroslav Holyak almost 14 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.
Updated by Ernesto Baschny almost 14 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).
Updated by Myroslav Holyak almost 14 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.
Updated by Ernesto Baschny almost 14 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.
Updated by Myroslav Holyak almost 14 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 stdWrap.date = Y-m-d H:m in time zone different from current server?
Updated by Ernesto Baschny almost 14 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.
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.
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.