Problem with "convert it to seconds"

Richard Gaskin ambassador at fourthworld.com
Fri Apr 29 02:31:06 EDT 2005


>  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. 

While the old HyperCard method failed to take DST into account when 
needed, when not needed the Rev method fails.

I'll toss in my votes for a way to let the developer choose the method 
most appropriate to the task at hand.

What's the Bugzilla #?

--
  Richard Gaskin
  Fourth World Media Corporation
  __________________________________________________
  Rev tools and more: http://www.fourthworld.com/rev


More information about the use-livecode mailing list