Time zones in CL

[T.Y Chew]

Hi folks,

I'm confused about the sign of time zones in CL:ENCODE-UNIVERSAL-TIME
and CL:DECODE-UNIVERSAL-TIME.

Here's our baseline, 0:00 1 Jan 1900. At the Greenwich meridian, this
is 0:00 in the morning:

(encode-universal-time 0 0 0 1 1 1900 0) ==> 0

Suppose we were to move instantaneously 1 hour East, to a timezone
that's GMT+1, our local time would now be 01:00 in the morning.

(encode-universal-time 0 0 1 1 1 1900 1) ==> 7200

I have to invert the timezone instead

(encode-universal-time 0 0 1 1 1 1900 -1) ==> 0

Similarly, from Greenwich, flying West by an hour, to GMT-1, requires

(encode-universal-time 0 0 23 31 12 1899 -1) ==> -7200

Again, the timezone here should be specified as +1

(encode-universal-time 0 0 23 31 12 1899 1) ==> 0

Common Lisp is consistent of course, in that decode-universal-time
will use the same sense as above, but why is this the opposite of what
I had expected? I suspect the timezone needs to be interpreted in some
"negative" sense. What gives?

Yong

[Antony]

On 2/20/2012 8:55 PM, T.Y Chew wrote:
> Common Lisp is consistent of course, in that decode-universal-time
> will use the same sense as above, but why is this the opposite of what
> I had expected? I suspect the timezone needs to be interpreted in some
> "negative" sense. What gives?

It just depends on the point of view.
when we say
...18:00-7:00
when it's 6PM PST
it means *add* 7 hours to get current GMT
So CL is conforms to the general convention

-Antony

[Alex Mizrahi]

PST would be +7 in CL's notation, so it is an opposite of "the general
convention".

http://clhs.lisp.se/Body/26_glo_t.htm#time_zone

time zone n. a rational multiple of 1/3600 between -24 (inclusive) and
24 (inclusive) that represents a time zone as a number of hours offset
from Greenwich Mean Time. Time zone values increase with motion to the
west, so Massachusetts, U.S.A. is in time zone 5, California, U.S.A. is
time zone 8, and Moscow, Russia is time zone -3. (When ``daylight
savings time'' is separately represented as an argument or return value,
the time zone that accompanies it does not depend on whether daylight
savings time is in effect.)

[Pascal J. Bourguignon]

That just shows the American origins of Common Lisp. When you are at
Greenwitch, you have to substract 7 from the hour to know the hour in
PST, but when you are in PSD, you have to add 7 to the hour to know the
hour in Greenwitch.

By the same token, (format nil "~R" n) writes American English numbers,
not British English numbers.


--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.

[Tim Bradshaw]

On 2012-02-21 08:42:39 +0000, Alex Mizrahi said:

> PST would be +7 in CL's notation, so it is an opposite of "the general
> convention".

$ TZ=GMT date
Tue 21 Feb 2012 10:35:48 GMT
$ TZ=GMT+7 date
Tue 21 Feb 2012 03:35:54 GMT

[Philip Guenther]

Yep, POSIX got it backwards too. To quote from
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08

----
The expanded format (for all TZ s whose value does not have a <colon>
as the first character) is as follows:

stdoffset[dst[offset][,start[/time],end[/time]]]
<...>
offset
Indicates the value added to the local time to arrive at
Coordinated Universal Time. The offset has the form:

hh[:mm[:ss]]
<...>
If preceded by a '-' , the timezone shall be east of the Prime
Meridian; otherwise, it shall be west (which may be indicated by an
optional preceding '+' ).
----


Contrast that with the revised email message format standards RFC
2822/5322 which say:
----
The zone specifies the offset from Coordinated Universal Time (UTC,
formerly referred to as "Greenwich Mean Time") that the date and
time-of-day represent. The "+" or "-" indicates whether the
time-of-day is ahead of (i.e., east of) or behind (i.e., west of)
Universal Time.
----
and later explicitly note that the old mnemonics have negative
meanings:
----
EDT is semantically equivalent to -0400
EST is semantically equivalent to -0500
CDT is semantically equivalent to -0500
CST is semantically equivalent to -0600
MDT is semantically equivalent to -0600
MST is semantically equivalent to -0700
PDT is semantically equivalent to -0700
PST is semantically equivalent to -0800
----

The original RFC822 cites this reference for the numeric form:
ANSI. "Representations of Universal Time, Local Time Differen-
tials, and United States Time Zone References for Information
Interchange," X3.51-1975. American National Standards Insti-
tute: New York (1975).

I wonder if some version of that has made its way online...


Philip Guenther

[T.Y Chew]

On Feb 21, 6:42 pm, Alex Mizrahi <alex.mizr...@gmail.com> wrote:

[[...]]

> http://clhs.lisp.se/Body/26_glo_t.htm#time_zone
>
> time zone n. a rational multiple of 1/3600 between -24 (inclusive) and
> 24 (inclusive) that represents a time zone as a number of hours offset
> from Greenwich Mean Time. Time zone values increase with motion to the
> west, so Massachusetts, U.S.A. is in time zone 5, California, U.S.A. is
> time zone 8, and Moscow, Russia is time zone -3. (When ``daylight
> savings time'' is separately represented as an argument or return value,
> the time zone that accompanies it does not depend on whether daylight
> savings time is in effect.)

Thanks for the comments everyone. I had had a read in the CLHS for the
respective functions, and about time itself, but did not look in the
glossary... :-)

Yong.

[Tim Bradshaw]

On 2012-02-21 21:16:15 +0000, Philip Guenther said:

> Yep, POSIX got it backwards too.

OK, so who actually got it right? And are you suggesting CL should do
things *differently* than POSIX?

[David Kaasen]

The ISO 8601 standard uses "+" for eastern zones:

The offset from UTC is given in the format +/-[hh]:[mm],
+/-[hh][mm], or +/-[hh]. So if the time being described is one hour
ahead of UTC (such as the time in Berlin during the winter), the
zone designator would be "+01:00", "+0100", or simply "+01".

(From Wikipedia).

Best regards from
David Kaasen.

[Alex Mizrahi]

>> Yep, POSIX got it backwards too.

> OK, so who actually got it right?

All user interfaces I've seen. Windows, Ubuntu, Nokia phone and so on.
Maybe it depends on locale, I dunno. (Pascal says that flipping tz is
american thingie, and that's plausible.)

> And are you suggesting CL should do
> things *differently* than POSIX?

ISO standard has way more weight than POSIX, so, yes. POSIX is like a
documentation for quickie hacks made by some 70s hackers, so I don't see
why it should be authoritative for other software products.

[Teemu Likonen]

* Tim Bradshaw [2012-02-22 10:51:32 +0000] wrote:

> On 2012-02-21 21:16:15 +0000, Philip Guenther said:
>> Yep, POSIX got it backwards too.
>
> OK, so who actually got it right?

See the "Date" header of this post. I live in Finland which is at
+02:00.

[Tim Bradshaw]

On 2012-02-21 08:42:39 +0000, Alex Mizrahi said:

> PST would be +7 in CL's notation, so it is an opposite of "the general
> convention".

OK, so let's say I'm in TZ 0 (which I am). What argument to I pass to
this function to get a time in PST:

(defun ts (offset)
(multiple-value-bind (second minute hour date month year day daylightp zone)
(get-decoded-time)
(declare (ignore day daylightp))
(decode-universal-time (encode-universal-time second minute hour
date month year
(+ zone offset)))))

(hint, the answer is not +7).

[Tim Bradshaw]

On 2012-02-22 16:51:36 +0000, Teemu Likonen said:

> See the "Date" header of this post. I live in Finland which is at
> +02:00.

Right:

(defun show-local-time (offset)

(multiple-value-bind (second minute hour date month year day daylightp zone)
(get-decoded-time)
(declare (ignore day daylightp))
(decode-universal-time (encode-universal-time second minute hour
date month year
(+ zone offset)))))

(show-local-time 2)
12
4
19
22
2
2012
2
nil
0

[tar...@google.com]

On Wednesday, February 22, 2012 4:32:39 AM UTC-8, David Kaasen wrote:
>
> The ISO 8601 standard uses "+" for eastern zones:

The ISO 8601 standard is from 1988, although presumably in development for a while before that. POSIX also dates from 1988.

encode-universal-time was certainly available before then.
I have been able to trace it back at least to the Lisp Machines, which would put the function usage in the late 1970s or early 1980s.

I can't recall if this convention was in place in MacLisp, though.

So it seems that the Common Lisp convention may predate some of the other standards for time zone encoding.

[Philip Guenther]

To say it again: how about a 1975 standard from ANSI?

ANSI. "Representations of Universal Time, Local Time Differen-
tials, and United States Time Zone References for Information
Interchange," X3.51-1975. American National Standards Insti-
tute: New York (1975).

Philip Guenther

[Alex Mizrahi]

>> PST would be +7 in CL's notation, so it is an opposite of "the general
>> convention".
> OK, so let's say I'm in TZ 0 (which I am). What argument to I pass to
> this function to get a time in PST:

How is this relevant? It is a function you've just wrote, it has its own
convention. While CL's convention is described in glossary entry I've
quoted, and you can check it via decode-universal-time alone, no need to
find combination of three function calls.

[Tim Bradshaw]

On 2012-02-23 09:00:40 +0000, Alex Mizrahi said:

> How is this relevant? It is a function you've just wrote, it has its
> own convention. While CL's convention is described in glossary entry
> I've quoted, and you can check it via decode-universal-time alone, no
> need to find combination of three function calls.

I'm trying to make three points.

Firstly, the sign of a timezone is just an arbitrary choice: you can
either treat it as mapping from the local time to universal time, or
the other way around, and the difference is a sign. So, using the ISO
convention, where zones to the east of UTC are positive, the timezone
maps from UTC to the local time, while using CL’s or POSIX’s, where
they are negative, the timezone maps from local time to UTC. Neither
is obviously better. And it’s *just a sign convention*: it is
obviously entirely trivial to convert one to the other, or to write a
wrapper which expresses one in terms of the other.

Secondly, standards do not define whether something is right or wrong:
they just define whether something is conforming to them. As other
people have pointed out, the timezone convention in CL predates ISO
8601 (the latest plausible date for it is 1984, and it might well go
back for a long time before that), but even if it didn’t CL does not
purport to conform to this standard. That’s fine, there are lots of
other standards which it does not conform to either.

Thirdly, if you think that one of these conventions is somehow
inherently better than the other, and even more if you think this
matters, then some guy called Swift wrote a story about eggs you should
read.

[Alex Mizrahi]

> Secondly, standards do not define whether something is right or wrong:
> they just define whether something is conforming to them. As other
> people have pointed out, the timezone convention in CL predates ISO 8601
> (the latest plausible date for it is 1984, and it might well go back for
> a long time before that), but even if it didn’t CL does not purport to
> conform to this standard. That’s fine, there are lots of other standards
> which it does not conform to either.

I'm not saying it's bad either.
But ISO probably just documents common practice which existed long
before. I'm not particularly enthusiastic about digging it up, though.

> Thirdly, if you think that one of these conventions is somehow
> inherently better than the other, and even more if you think this
> matters, then some guy called Swift wrote a story about eggs you should
> read.

Um, for a language designed today following ISO is better, as users will
see same offsets as they see in user interfaces, so chances for error
are lower.

BTW is there even a way to get "CL style" timezone out of `date` (in GNU
coreutils)?

$ date -u
Fri Feb 24 11:38:14 UTC 2012

$ date --rfc-822
Fri, 24 Feb 2012 13:37:23 +0200

$ date --rfc-3339="seconds"
2012-02-24 13:39:20+02:00

$ date "+%z"
+0200

[Frank DG1SBG]

"T.Y Chew" <senator...@gmail.com> writes:

> Hi folks,
>
> I'm confused about the sign of time zones in CL:ENCODE-UNIVERSAL-TIME
> and CL:DECODE-UNIVERSAL-TIME.

[..]

See http://naggum.no/lugm-time.html .

Frank