Subject: Re: (en|de)code-universal-time
From: Erik Naggum <clerik@naggum.no>
Date: 1998/04/09
Newsgroups: comp.lang.lisp
Message-ID: <3101073745421171@naggum.no>


* Sam Steingold <sds@usa.net>
| Sinister laughter: I have access to 4 CL implementations, and each has
| it's own idea of what (en|de)code-universal-time should do.

  this is an unwarranted conclusion.  what you observe is all in agreement
  with the specification.  your failure to supply a time zone is a problem
  in your usage of these functions.  a full time specification contains the
  universal time _and_ the timezone.  human conveniences regarding the
  ability to default various parts of our information because it is
  recoverable from context does not go well with computers.  remember the
  mistakes that have caused the Year 2000 hysteria with people who forgot
  to tell the computer about their assumptions?

  the only valid gripe here is that the various Lisps do not work well with
  the underlying operating system's ideas about time zones and daylight
  savings time, but this is also an extremely annoying problem.  as far as
  I know, all four Lisps refuse to use the Unix timezone system provided by
  the (Unix) vendor, and get most of the more recent developments wrong.
  with _no_ way to provide additional time zone information, such as to
  update the obnoxious "daylight savings time" switch-over dates, which is,
  of all things, subject to _political_ randomness, we're basically out of
  luck with the correct time of day in Lisp.

| I read CLHS and I think CLISP is correct (I am located in Princeton, NJ,
| USA).

  if you know where you are, why don't you tell your Lisp where you are,
  instead of just telling us?  :)

  despite what I said above, most Lisps have a way to let them know what
  the default timezone should be.  in Allegro CL (always for Unix), it is
  EXCL::*TIME-ZONE*.  this is also set by EXCL::INIT-TIME-ZONE, which takes
  an argument like "EST5EDT".

  Allegro CL 4.3 and above seems to understand the local time zones when
  built and dumped locally, however.

| Note that each implementation returns its own encode-universal-time, and
| each has a different idea about the current time zone.

  well, the two _are_ very closely related, so what do you expect?  :)
  they shouldn't differ in the value from GET-UNIVERSAL-TIME, however.

#:Erik
-- 
  religious cult update in light of new scientific discoveries:
  "when we cannot go to the comet, the comet must come to us."