[Typo3-dev] TimeStamp problem

[Olivier Simah]

Hi,
I am using the ScoutNet calendar and I noticed the strange behavior describe
in the below message.
Does anyone nows how to fix this problem and why the time are stored using
JavaScript and not PHP ?

Thanks for your help

Olivier

//**************************************************
//**************************************************

Hi guys,

any javascript guru's out here? I'm a bit at a loss...

I was working on a simple custom "calendar of events" extension, when I
noticed something strange.
the extension has two date-fields and two time-fields. I wanted to give
the user options on how to display the dates/times, which meant using
strftime() or gmstrftime(), which respectively formats a unix-time stamp
according to local of as gmt time. yes: all date and time fields in typo3
are stored as timestamps.

now what happened: either the date was off by a day or the date was off by
an hour according to the timezone setting.

digging into the javascript which accounts for the formatting and
evaluating of date/time fields in the backend, I found that:

*) dates are stored according to local time using the javascript "Date"
object. This means that 1-1-2003 (0:00 hours) is stored as the timestamp
for gmt 31-12-2002 23:00.

*) times are stored (at least formatted) according to gmt time (by manual
multiplication with 3600 secs and 60 seconds respectively for hours and
minuts)

*) datetime fields are mixed

Ok, I tried changing the time-formatting behavior to local time (using
Date), which means that dates are correctly displayed in the backend as
local time.

(all functions below are in the file t3lib/jsfunc.evalfields.js
in evalfunc_output(...), case "timesec" I changed

var h = Math.floor(value/3600);
var m = Math.floor((value-h*3600)/60);
var s = Math.floor(value-h*3600-m*60);

into:

var h = theTime.getHours();
var m = theTime.getMinutes();
var s = theTime.getSeconds();

Now comparing the actual timestamp, and the time displayed, this correctly
displays local time.

However, now the evaluatin function is malfuntioning. If you change the
date displayed by adding 1 minute, it is evaluated by adding an extra
hour! This could be explained if the evualing function is also using gmt
or manual manipulations, but it doesn't!

now, a working solution is:

in evalfunc_input(...) add

var gmt =
Date.UTC(today.getYear(),today.getMonth(),today.getDate(),today.getHours(),0
,0);
var lt = new
Date(today.getYear(),today.getMonth(),today.getDate(),today.getHours(),0,0);
var lt = lt.getTime();
var offset = (lt-gmt)/3600000;

the offset is the number of hours difference between local and gmt time.
so in the same function, under "case timesec" we change

var hour =
(values.values[1])?this.parseInt(values.values[1]):today.getHours();
if (hour > 23) {hour=23;}
var theTime = new Date(this.getYear(today),
today.getMonth(), today.getDate(), hour, min, ((type=="timesec")?sec:0));

into this:

var hour =
(values.values[1])?this.parseInt(values.values[1]):today.getHours();
hour=hour+offset;
if (hour > 23) {hour=23;}
var theTime = new Date(this.getYear(today),
today.getMonth(), today.getDate(), hour, min, ((type=="timesec")?sec:0));

which makes the time being stored as gmt.

my guess is that this also works for "datetime" fields, where this
timestamp value is added to the timestamp of the date (and addition should
only be made in gmt time?)

Ok, but....!?

I feel that this is not a good solution either.

datetime should be stored as gmt and be displayed using local time
date & time fields should be stored as gmt and displayed as gmt

it makes no sense to have to set timezones in order to avoid the date
(when it is meant as a simple date) being of by a day. the same goes for
the time fields: 19:00 hours is meant as 19:00 hours, not as -3 hours (if
you are in a completely different zone).
this is different for datetime fields, where changing a timezone would
make sense since you point to an actual moment in time, which is different
in different timezones.

this would mean radical changes of the file t3lib/jsfunc.evalfield.js...
and I'm not absolutely sure where to start. the problem is that this has
impact also on your data (being stored in timestamps).

also, extensions should than follow the convention of using "strftime" for
datetime fields, and "gmstrftime" for date or time fields.

I'm curious what you think about this... because I cannot just change this
file for my needs for this extension, since it will impact in lots of
places (backend, extensions).

greetz, Luite.


-----------------------------------------------
AEGEE-Utrecht - De Europese Studentenvereniging

[TOP]  12-03-2003 12:03  by  Kasper Skårhøj,   kasper(AT)typo3.com
kasper

In reply to Luites findings I once made this report which describes the
problem and the despair of it all:


>First of all I could not see the error for the date "20-4-1997", only for
>"20-4-1979". However digging into it you find that:
>
>- Dates from 26/3 to 28/10 (inclusive) will have one hour (3600 seconds)
>subtracted from their Unix-timestamp
>- Dates in the winter-interval will not.
>- Furthermore it's the JavaScript that makes the "error" - not PHP. PHP is
>working linear with the dates.
>- Further I tried on both MSIE 6 AND the newest mozilla - they made the
>same error.
>
>
>This smells a LOT of daylight-saving!
>
>However the really strange thing is that
>- It does so ONLY for the years 71-79, 82-85, 88-91, 93-95
>- BUT if one try the date 1/7 (middle of summer) then all years from 1970
>to 1980 are the only ones adjusted for daylight saving.
>- And generally playing with the dates at different years reveals even
>more mystique.
>
>
>My theory is that this is no browser-specific thing, because it happens in
>both MSIE and Mozilla. Rather they get their time from the system and I
>suspect that the OS (in my case WinXP) is delivering the dates. However it
>seems to be totally buggy. For instance a year like 1982: Why would it
>correct dates from 31/3 to 6/4 and 29/9 - 26/10 ONLY. Daylight saving
>lasts all summer, not only a week and a month!
>
>
>I don't know how to solve this problem except making my own JavaScript
>function which can calculate the correct UNIX timestamp based on
>year-month-day-hour-minute-second input. But this function should probably
>take leap-years into account etc.
>
>The problem with this is that in the date-fields of Typo3 we are entering
>dates like "19-10-2002" which implicitly means "19-10-2002 00:00:00".
>However if this bug described here occurs the STORED value will be
>"18-10-2002 23:00:00" (that is one hour less). And so if you process the
>date in PHP you will NOT see 19-10-2000 but 18-10-2002.
>
>If someone could write the JavaScript function described above then we
>might be able to fix this bug. This IS something somebody else could do
>and test. Right now I'm pretty tired of thsi kind of problems.



- kasper



begin 666 user2.gif
M1TE&.#EA$@`0`)'_`(C,4BQD`/___P```"'_"T%$3T)%.DE2,2XP`M[M`"'Y
M! $```(`+ `````2`! ```(NE(^I%^V;W(-&VF4E"#B##6G?QG7-.):1^*FK
5@[K*&5,5V=@"#5*T9..E=$1!`0`[
`
end