Problem with "convert it to seconds"

[Sarah Reichelt]

> When using the convert function in Rev cgi Linux and
> in Rev Mac OS9 (or Win XP) I get different results :
> - Rev cgi : 1114427491
> - Rev Win XP : 1114423891
>
> There's a 3600 seconds difference, and I vaguely remember
> a discussion (in the old MC days) about the fact that the cgi
> engine calling a unix convert function that doesn't take into
> account the summer / winter time change...
> Anyone has some info about this (or a workaround) ?
>
WARNING: long rant about Rev's time handling!!

I have only encountered this on Mac OS X but it is a real problem. I 
can confirm that it happens, but the only solution I worked out used 
AppleScript. There may be a Unix method you could use, so I'll explain 
what I do.

In Rev, I use "the internet date" to give me the time zone (it's the 
last word), then I use AppleScript to give me the number of minutes to 
GMT. AppleScript gives me the time zone INCLUDING any daylight savings 
component, rev's gives me the time zone ignoring daylight saving. I 
then use the difference between these 2 to get the current amount of 
daylight savings time, so I can apply this as necessary.

I have a further problem with "the seconds" which I will describe in 
case anyone else finds it a problem. It reports the number of seconds 
since midnight on 1/1/1970 GMT. The fact that it is GMT is crucial as 
it means that the number returned by the seconds is not an absolute 
date & time but depends on the time zone of the computer that is 
converting it. For example, I operate a remote computer in a different 
time zone that logs certain events using time stamps in seconds. It 
then sends me that log and I convert the time stamps to date & time. 
Because I am in a different time zone, the times change.

I am in time zone +1000 and the remote computer is in +0930. A log 
entry gets added at the remote computer at 5:30 am. It sends me the 
report and the log entry gets translated as having happened at 6 am. 
Now it was 6 am for me when it happened, so the seconds is reporting 
the actual moment in time, but I want to know what the local time was 
when the event happened, so again I am forced into weird convolutions 
where I have to allow for differences in time zones whenever data is 
transferred from a remote machine.

While I am stuck using the seconds because other programs depend on 
getting data in that format, I recommend using another method if at all 
possible. Julian time would now be my preferred option for a numeric 
time stamp. Unfortunately, my system originally used HyperCard where a 
numeric value in seconds ALWAYS translated to the same date & time 
regardless of time zones.

If you want to test this, try the following script:

put 1113336031 into t
convert t to short date and long time
put t

If I use my local time - Brisbane, Australia (+1000), I get: 4/13/05 
6:00:31 AM
But if I switch to Adelaide, Australia (+0930), I get:  4/13/05 5:30:31 
AM

You will get a varying date & time depending on your local time zone 
and current daylight savings setting.

Cheers,
Sarah