From mboxrd@z Thu Jan  1 00:00:00 1970
X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/9576
Path: main.gmane.org!not-for-mail
From: visigoth@naiad.fac.cs.cmu.edu
Newsgroups: gmane.emacs.gnus.general
Subject: Re: Statistics'R'Us
Date: 23 Jan 1997 05:59:48 -0500
Sender: visigoth@naiad.fac.cs.cmu.edu
Message-ID: <vpdlo9klkrf.fsf@naiad.fac.cs.cmu.edu>
References: <m24tgi45u2.fsf@proletcult.slip.ifi.uio.no> <vpd7ml72fw8.fsf@naiad.fac.cs.cmu.edu> <x7buajarw0.fsf@mastaler.com> <vpdafq2ol9u.fsf@naiad.fac.cs.cmu.edu> <m23evupqvk.fsf@proletcult.slip.ifi.uio.no> <vpd3evunnql.fsf@naiad.fac.cs.cmu.edu> <m24tg95d06.fsf@proletcult.slip.ifi.uio.no> <vpdenfdqac8.fsf@naiad.fac.cs.cmu.edu> <m2k9p44ut8.fsf@proletcult.slip.ifi.uio.no>
NNTP-Posting-Host: coloc-standby.netfonds.no
Mime-Version: 1.0 (generated by tm-edit 7.93)
Content-Type: text/plain; charset=US-ASCII
X-Trace: main.gmane.org 1035149579 19274 80.91.224.250 (20 Oct 2002 21:32:59 GMT)
X-Complaints-To: usenet@main.gmane.org
NNTP-Posting-Date: Sun, 20 Oct 2002 21:32:59 +0000 (UTC)
Return-Path: <ding-request@ifi.uio.no>
Original-Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2])
	by deanna.miranova.com (8.8.5/8.8.5) with SMTP id DAA14383
	for <steve@miranova.com>; Thu, 23 Jan 1997 03:25:26 -0800
Original-Received: from naiad.fac.cs.cmu.edu (NAIAD.FAC.CS.CMU.EDU [128.2.191.173]) by ifi.uio.no with SMTP (8.6.11/ifi2.4) 
	id <MAA01530@ifi.uio.no> for <ding@ifi.uio.no> ; Thu, 23 Jan 1997 12:00:21 +0100
Original-To: ding@ifi.uio.no
In-Reply-To: Lars Magne Ingebrigtsen's message of 23 Jan 1997 10:14:43 +0100
Original-Lines: 31
X-Mailer: Red Gnus v0.82/XEmacs 19.14
Source-Info: Sender is really visigoth@naiad.fac.cs.cmu.edu
Xref: main.gmane.org gmane.emacs.gnus.general:9576
X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:9576

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.