Re: Statistics'R'Us

[visigoth@naiad.fac.cs.cmu.edu]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

> Does `encode-time' expect the ZONE to be in seconds?  

Yup--that's how I was able to recognize what was going on.  Going from
one timezone to another with times that should be equivalent was
producing unix-times that were 3500 seconds off per timezone jump...
Since a timezone jump is "0100", and there a 3600 seconds in an hour,
I saw what was going on.

Oho!

Even better--I just found the documentation I had been looking for.

>From decode-time (which encode-time refers to):

> ZONE is an integer indicating the number of seconds east of Greenwich.

>From encode-time:

> This can be a string (as from `set-time-zone-rule'), or it can be a
> list (as from `current-time-zone') or an integer (as from
> `decode-time') applied without consideration for daylight savings
> time.

So--the best thing to do appears to be to take the time-zone string
and throw it in as the time zone.  The problem occurred because you
were numerifying the time-zone, which was then interpreted as seconds
from GMT.

John.