I ran into a bug in LispWorks 4.1.20 where on Linux they were not accepting
a NIL timezone but on Windows they were. They've fixed this for their next
release, but I wanted to take a quick survey before they come out with it
one way or the other to find out how other vendors do this and whether they
fixed it "in the right way".
In particular, they've fixed it to make a NIL argument illegal. This is
easily justified because the standard doesn't say what it defaults to or
how to treat a default such as NIL.
On the other hand, I'd prefer it tolerate NIL as meaning "unspecified" so
that I don't have to write:
(if tz
(encode-universal-time sec min hr date mon yr tz)
(encode-universal-time sec min hr date mon yr))
every time I want to call this function with a suspect timezone.
What do other implementations do with this case? If anyone else
(especially vendors, but also other users who've thought a lot about
time, like Erik) has an opinion on this, could you voice it now?
Thanks.
--Kent
>>>>> "kmp" == Kent M Pitman <······@world.std.com> writes:
kmp> What do other implementations do with this case?
CMUCL, CLISP and Corman Lisp handle NIL the same as no argument (seems
logical to me for an &optional argument). GCL and OpenMCL-beta expect
a numeric argument and raise an error.
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
Kent Pitman wrote:
> In particular, they've fixed it to make a NIL argument illegal. This is
> easily justified because the standard doesn't say what it defaults to or
> how to treat a default such as NIL.
>
> On the other hand, I'd prefer it tolerate NIL as meaning "unspecified" so
> that I don't have to write:
>
> (if tz
> (encode-universal-time sec min hr date mon yr tz)
> (encode-universal-time sec min hr date mon yr))
>
> every time I want to call this function with a suspect timezone.
>
> What do other implementations do with this case? If anyone else
> (especially vendors, but also other users who've thought a lot about
> time, like Erik) has an opinion on this, could you voice it now?
I am neither an implementor nor a great expert on time;
but I share your preference, by a substantial margin.
--
Gareth McCaughan ················@pobox.com
.sig under construc
From: Kent M Pitman
Subject: Re: Optional timezone in ENCODE-UNIVERAL-TIME
Date:
Message-ID: <sfw7kxyagvp.fsf@world.std.com>
················@pobox.com (Gareth McCaughan) writes:
> Kent Pitman wrote:
>
> > In particular, they've fixed it to make a NIL argument illegal. This is
> > easily justified because the standard doesn't say what it defaults to or
> > how to treat a default such as NIL.
> >
> > On the other hand, I'd prefer it tolerate NIL as meaning "unspecified" so
> > that I don't have to write:
> >
> > (if tz
> > (encode-universal-time sec min hr date mon yr tz)
> > (encode-universal-time sec min hr date mon yr))
> >
> > every time I want to call this function with a suspect timezone.
> >
> > What do other implementations do with this case? If anyone else
> > (especially vendors, but also other users who've thought a lot about
> > time, like Erik) has an opinion on this, could you voice it now?
>
> I am neither an implementor nor a great expert on time;
> but I share your preference, by a substantial margin.
Thanks! I realized after I sent this that I shouldn't have been so
exclusionary. Some of the issue relates to the dynamics of whether it
means something semantically different if you omit the thing, and I
figured only the people who've looked at the "algebra" of this would
know that really well. But I also do appreciate knowing what people
in general think about this kind of issue from just a program calling
point of view, so I'm glad I didn't scare you off...
From: Erik Naggum
Subject: Re: Optional timezone in ENCODE-UNIVERAL-TIME
Date:
Message-ID: <3202619693677506@naggum.net>
* Kent M Pitman <······@world.std.com>
> On the other hand, I'd prefer it tolerate NIL as meaning "unspecified" so
> that I don't have to write:
>
> (if tz
> (encode-universal-time sec min hr date mon yr tz)
> (encode-universal-time sec min hr date mon yr))
>
> every time I want to call this function with a suspect timezone.
I usually call encode-universal-time with apply, so I see the difference
in behavior a little less, and a little more: When there is a timezone
argument, it is interpreted as a constant, but when it is unspecified,
the complex rules that go into whatever concept the standard does not
define for "current timezone", daylight saving time "algorithms" are in
effect. I think there is a semantic difference between these two
timezone calculations and because of the way the function is specified,
there is a sharp line of demarcation between the known and the unknown
timezone. I think the current definition reflects this properly.
<soapbox>Timezones are not simple creatures. Time is far more complex
than this universal-time implementation attempts to make it, too. If we
use universal-time to measure duration, we almost do fine, except that
the real-time clock on most computers both drift and correct drift, the
earth drifts and has its drift corrected, and we end up with a measure of
duration that is nigh useless in the general sense, although meaningful
values may be obtained in special cases, when the environment is known.
That problem is so much more present in dealing with timezones. Time is
not a one-dimensional value, it is at least a two-dimensional value.
Because people and computers are mostly stationary, we forget the "where"
of time measurements. (And of course such relativistic properties as the
speed and the gravitational environment. :) However, timezone indication
is a first-order approximation to the location of the time measured, but
knowing the numeric timezone of a particular time measured is completely
useless for anything but that particular time. One second later, you may
have crossed the daylight saving time borders, leaping forward og going
backward in local time terms. Set out from one city and expect to arrive
in another, the journey taking five hours, can you tell the local time
when you arrive? Generally, no. You have to know the local customs of
time distortion just to know what time it is, and you must also know the
local customs of time misrepresentation to express it in a way that the
locals can deal with. And that is just the beginning of why time travel
will never work right.</soapbox>
There is only one _real_ solution to this problem: Abandon timezones.
Use only coordinated universal time, timezone 0 in Common Lisp terms, no
matter where you are on the planet. If your politicians need to force
the workers of their countries to get up an hour earlier in the summer to
get that precious hour of extra sun when they leave work, which is the
current idiotic excuse to perpetuate daylight saving time, change the
opening/working/whatever hours during "summer" or whatever, just do not
let politicians mess with the representation of time. Please.
In contrast to the real solution to this complex problem, the irrational
solution that will spread satisfaction among all kinds of clueless users
who still think of time as whatever some clock says it is, is to make a
timezone object that reflects the past idiotic decisions of daylight
saving zealots and try to predict their future idiotic decisions so that
this can all be simplified greatly. This may be done with a huge mass of
tables that are kept on the local computer (network), propagated and
updated at random by semi-conscientious system administrators, colliding
with those updates that are published by semi-conscientious vendors of
software that actually need them. A better solution would of course be
to use a geographical/universal coordinate system and query a DNS-like
infrastructure for the timezone at that location at a given time, but we
are very far from that blissful situation, and even if we were to build
it, it would take approximately 1000 years for Microsoftians to get with
the program, because those guys still keep time in local time internally.
#:Erik, sighing, sobbing, almost
--
Travel is a meat thing.
From: Kent M Pitman
Subject: Re: Optional timezone in ENCODE-UNIVERAL-TIME
Date:
Message-ID: <sfw4rt218cm.fsf@world.std.com>
Erik Naggum <····@naggum.net> writes:
> <soapbox>Timezones are not simple creatures. ...
"Yes, Mrs. Lincoln, but aside from that, how did you like the play?"
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?
From: Erik Naggum
Subject: Re: Optional timezone in ENCODE-UNIVERAL-TIME
Date:
Message-ID: <3202669002590688@naggum.net>
* Kent M 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.