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
_______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com http://lists.runrev.com/mailman/listinfo/use-revolution
