Subject: Re: Optional timezone in ENCODE-UNIVERAL-TIME From: Erik Naggum <firstname.lastname@example.org> Date: Wed, 27 Jun 2001 22:16:44 GMT Newsgroups: comp.lang.lisp Message-ID: <email@example.com> * Kent M Pitman <firstname.lastname@example.org> > 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.