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