Subject: Re: (en|de)code-universal-time From: Erik Naggum <email@example.com> Date: 1998/04/09 Newsgroups: comp.lang.lisp Message-ID: <firstname.lastname@example.org> * Sam Steingold <email@example.com> | 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."