TYPO3 Core

maybe this has something to do with the server time zone or the time zone of the user? I don't know, just an idea.
greets, sebastian

The server runs on CEST, as does my local machine. With this configuration, the bug occurs.

it seems that this issue can happen in both directions (see related bug).
Greets, Sebastian

Hi, (Reply from 0001465)

Server runs CEST, client runs CEST both GMT+1.
I can only replicate the bug with this date (2:00 26-3-2006 till 23:59 26-3-2006). Trying the date above (18:00 30-10-2009) ends in expected result.
In "my" case s.th adds an hour (input 2:00 26-3-2006 s.th. changes it to-> 3:00 26-3-2006). spooky

Tested clients with same bug-appereance:
IE (6.0.2800.1106) wk2
FF(1.0.7) wk2
FF (1.0.6) debian sarge (same machine where typo3 runs on)
Opera 8.5(7700) wk2
Konqueror 3.3.2 KDE 3.3.2 debian sarge (same machine where typo3 runs on)

Hi hardcoder,
I can duplicate this here. Interesting...
Will have a look at it.
Greets,
Sebastian

current debugging location: jsfunc.evalfield.js
evalFunc_output case datetime

Hi folks,
I can't reproduce this here... The JavaScript that evaluates the form field seems to be ok...

I will test this on some other machines tomorrow

Greets,
Thomas

currently, I cannot do anything about it. Maybe we need some JS guru looking at it.
Greets, Sebastian

I have problem like this:
I have server in USA (GMT -5), my customer is in USA to.
Server Timezone looks OK.
In localconf.php:
$TYPO3_CONF_VARS["SYS"]["serverTimeZone"] = '-5';

I am in Russia (GMT +3).

I do content input.
I must spend a lot of time with tt_news date.
I must set it +1day to get correct date in FrontEnd.

So it will be very good to have possibility to set Timezone per BackEnd user
In this case I simply set my BackEnd user timezone to GMT-5 and all will be OK.

just to confirm vrom's comment:
- Server in Austria,
- [SYS][serverTimeZone] = 1 fine
- BE-Editor from Canada with Canadian Timezone set in the OS, sees and writes differing date/time values than a BE-Editor from AT with GMT set.
- observerd for tt_news and normal Pages-Start-Stop
- seems to me the JS Function for date display & input does reflect the Client-timezone somehow;

an additional Config-Option: Timezone per BackEnd user/ group, seems to be the best solution;

regards georg

We should decide if we want to stay with the users local time (and all the problems that come hand in hand) or if we switch to UTC (independent of the users local time(zone)) in TYPO's javascript scripts.

See
http://www.elated.com/tutorials/programming/javascript/dates/
for reference (search for "About UTC")

This should not be a problem with the provided getUTC* and setUTC* functions (available at least since Javascript 1.5)

I had :) this problem on a Intranet for a customer.

The server was set to CET (MET, GMT+1) and one of the editors had his timezone set to an EET (Easter European Time, GMT+2). The result was the following: When the editor (GMT+2) changed a value field for example to (0:00) 1-1-1970 the resulting timestamp gets calculated on the Client-Machine (not on the Server). As a UNIX timestamp doesn't have a timezone the correct timestamp value for 0:00 1-1-1970 when it get's calculated on a machine with GMT+2 is -7200 (it is 22:00 31-12-1969 at the same moment in Greenwich). So -7200 gets stored on the server.

When this value (-7200) gets displayed in the FE by using strftime the value get's converted to the date using the timezone of th server (GMT+1). -7200 seconds using GMT+1 equals 23:00 31-12-1969 ... which is of course 1h before the value which was originally inputed by the editor.

I created a patch which works as following:
The timezone in which the server runs get's always transmitted with a TCE-Form. Whenever a date-value get's inputed the timestamp as seen from the server for the given date get's stored in the hidden field, transmitted to the server and stored in the DB. When the field get's shown again the server-timestamp get's converted to the local equivalent again so the display in the BE is correct.

The patch is called "bug_1697.diff" from 17.01.2006

The latest patch (2006-01-20) fixes this issue by solving it with the following logic:

Every date which get's inputed means the value inputed as if you were in the timezone of the Server.

To activate it check the [SYS][respectTimeZone] checkbox in the install tool.

Daylight-savings times are respected if set up correctly in the clients-browsers machine.

The latest two patches are the same as the CVS version but for those who need it for 3.8.0

ask me via private mail if you need them for 3.8.1.

there are versions for the .zip and .tar.gz packages as the files in t3lib are also located in typo3/t3lib/ which are symlinks in the tar.gz versions and for those reasons don't need to get patched twice.

I uploaded a new version of the timezone fixes to this bug-entry.

The problem with the 3.8.0 backported fixes was that 2 lines had to get swapped.

still see this bug in typo3 4.0.0
any news?

please take a look. would be nice to have fix of this critical bug in next release(4.0.1 or 4.1.0).

Any news on this?

I can confirm, that this bug exists in TYPO3 4.0.4

Ok, since this issue has a high priority to me, I tried to develop a patch (*_timezone.txt) against the svn TYPO3core.

Here is what I did:
Because the problem is the client, who can be all over the world, I changed the client JS to calculate all values on a GMT base. Now to get everything working with that value, the tceform date and time fields have to subtract the server timezone-offset from the timezone before passing it to the client (that should result in a GMT timestamp then). And the tcemain will receive a GMT based timestamp from the client and has to add the server timezone-offset to adjust the value to the server timezone.

Maybe my solution has still some bugs, but I think we should get this thing solved!
Thanks, Mario

Mario,

unfortunately your patch doesn't work for me. I have default serverTimeZone (=1). When I create a new tt_news record:

- Date defaults to current date ("15:17 26-3-2007").
- I change the hour, so I have: "18:17 26-3-2007"
- I change to another field. Date ist changed into: "20:17 1-1-1970"

So something is buggy still. Could you check?

If you can, please create a single patch file for all the changes. It is easier for us to apply and easier to revert the changes also.

As soon as I see a working patch, I will try to make it revieweable in core so that we can have that "in" a later 4.1 release.

Thanks for contributing!

Hi Ernesto,

I fixed some issues in jsfunc.evalfield.js and I combined all changes in one file - though I'm not sure if it's correct. SVN lets me only create a patch for one single file at a time. As a result I copied everything together. I hope it still works that way.

Thanks for catching up on this bug :)
/Mario

Hi Mario, thanks for the new version. Still buggy, thou.

Doesn't work:
- Date entered: 11:00 11-3-2006
- TAB. Date changed to: 12:00 11-3-2006

Works:
- Date entered: 11:00 11-4-2006
- TAB. Date changed to: 11:00 11-4-2006

As you see, only one month different.

I think the problem are the different outputs of getTimezoneOffset() depending on wether the date entered and the current date are in the same daylight saving time. We are now in DST here in Germany (since last sunday), which means getTimezoneOffset() on my CURRENT date Date() returns -7200 (-2 hours to UTC). But getTimezoneOffset() on 11-3-2006 will return -3600 (-1 hour to UTC), which should be what is used when calculating the hour offset on that specific date.

PS: To create a svn patch for all files, you need to go to the root of your typo3_src and do a "svn diff", which will go recursively through all directories and make a simple diff output. This should also make relative path names, which we can apply straight away on our sources. Your patches have headers like:

--- /Users/mariomatzulla/Documents/workspace/php/svn_t3lib/jsfunc.evalfield.js (revision 2000)
+++ /Users/mariomatzulla/Documents/workspace/php/svn_t3lib/jsfunc.evalfield.js (working copy)

Which means we have to calculate the number of path segments to strip when applying your patch (-p7 in that case). And "svn_t3lib", that is not really the name of the directory in typo3_src. So I am pretty sure you did something ugly to create that patch that can be done much easier. :)

Cheers,
Ernesto

2:00 26-3-2006 is the date where in 2006 the changed from wintertime to summertime. So this doesn´t exist in germany. I think that (at least especially this date in germany timezone) is not ab bug.
http://www.uhrzeit.org/zeitumstellung.html
Perhaps this is clear for other people. But i needed a half day to realize this. ;-(

So if someone can repoduce this problem with other times/dates, he/she should tell also the timezone on client and server.

But the other problem is, that the time is saved as unixtime from the local timezone. This should be changed to the unixtime in GMT/UTC.

Sorry, but I couldn't create relative path names. I'm using eclipse and have checked out the TYPO3core/trunk/t3lib as svn_t3lib. When I create a patch from the root of that project I'm getting the result I just uploaded. Please bear with me :)

/Mario

Ok, after a long and productive "night session" with Mario and me reviewing, testing and improving the latest patch, we have created "THE PATCH". Attached to the bug report. Let's see what you think.

Another enhancement in the same area:

http://www.baschny.de/timeoutput-dblist.diff

This corrects the output in the list-view for fields with eval = "timesec" (hh:mm:ss) and "time" (no seconds: hh:mm)

Wow ! First of all many thanx for that session, this is a big step to be time-safe with different timezones. A big hand for Ernesto and Mario - i apply the patch and report problems if there any.
short question - why is last patch not attached here ?

(Developer Days are very good for Typo3 :-) )

Use the T3X_user_datetest-0_0_0-z.t3x extension to test all possible date fields in one single table.

Well dear monitoring gals and guys on this old bug report.

What about someone really testing the attached patch that potentially solves this particular bug which haunts you every time your customer asks why the date-times are not stored correctly when they use TYPO3?

There is a very detailed description on how to test it:

http://lists.netfielders.de/pipermail/typo3-team-core/2007-April/008052.html

Please report your findings here ASAP, so that we can include that in 4.2!!!

So what's the intended / expected behavior at all?

To me the best solution will be:
possibility to disable all this date-time transformation.

So editor will see exactly what he input in all places (in BE form, in BE list module, in FE).

I do not understand, why this transformation was made. I think "no date-time transformation" will be the best solution for majority of TYPO3 installations.

Commited to trunk. rev. 2752