Subject: Re: Optional timezone in ENCODE-UNIVERAL-TIME
From: Erik Naggum <erik@naggum.net>
Date: Wed, 27 Jun 2001 22:16:44 GMT
Newsgroups: comp.lang.lisp
Message-ID: <3202669002590688@naggum.net>

* Kent M Pitman <pitman@world.std.com>
> You said the various arities had different semantics.  Does that mean
> you think it's better to signal an error if the tz argument is NIL?

  Yes.

  If you rely on the default or current timezone, communicating that could
  be done with a null timezone argument, but I read that as "I want a
  specific, numeric, constant timezone, but I have no idea what it is" or
  perhaps "please use the current timezone and daylight saving algorithms
  and everything which you would have done if I had wanted no timezone,
  even though I want a timezone".  It is somewhat like complaining that
  (/ 2) yields something different than, say (/ 2 10).

  I think you should never, _ever_ just test if you get a timezone argument
  to one of your own functions and use its absence as the basis for a
  decision whether to use the system default algorithm.  One the one hand,
  encode-universal-time s well-defined in both cases, but it really is two
  different functions that are "overloaded" based on argument count.  On
  the other hand, the two operations should have been separated, such that
  you could ask the system what the timezone of the particular time would
  be, such that you could give that value to the function with the timezone
  argument.  Lacking the latter separation, I think we are doing ourselves
  a disservice in perpetuating the kind of overloading present in this
  function (and in decode-universal-time) to user functions.

#:Erik
-- 
  Travel is a meat thing.