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

* Kent M Pitman <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.