Chaim Frenkel said:
> BB> Unfortunately, the valid range of time supported is easily determined,
> BB> and disturbingly short:
>
> BB> Into the future: to next December 31st or June 30th, whichever is
> BB> closer.
> BB> Into the past : to past January 1st or July 1st, whichever is
> BB> closer.
>
> Sorry, this makes no sense.
I am assuming that the system clocks are set accurately to UTC (or some
derivative, like (US) Eastern Standard Time). UTC is what time-servers
report. UTC has leap seconds, which are inserted (or, theoretically,
deleted) at the end of December 31st and June 30th, as needed.
This means that 86400 seconds (one day) after 2000 Dec 31, 12:00:00 UTC
is not necessarily 2001 Jan 1, 12:00:00 -- it could be 11:59:59 or
12:00:01 as well. And there is no way to know that ahead of time.
Any attempt to convert from a time-from-epoch representation to a
date-time representation has to deal with leap seconds, or it's not
computing UTC. MJD, for instance, is specifically not supposed to work
with UTC, because of leap seconds (it's based on UT, which doesn't have
leap seconds).
What happens on UNIX systems is that localdate() ignores leapseconds,
and as such there is a slow, subtle skewing of when the epoch is
(relative to UTC) -- a skewing that is time-dependent. A timestamp
made in mid-1990 has a different epoch (00:00:15 UTC 1 Jan 1970) than a
timestamp made in early 1999 (00:00:22). Most people ignore this
skewing, and get away with it. After all, it is a little less than one
second/year. But it is still there.
>
> BB> Leap-seconds are a PITA for generic time routines.
>
> Why?
Because they are inserted in a non-deterministic way.
According to httP//tycho.usno.navy.mil/leapsec.html, the Bureau
International des Poids et Mesures (BIPM) recommends that systems which
cannot handle leapseconds use TAI (International Atomic Time) instead.
If we have to pick and epoch in an OS-neutral way, I think I for one
would be happy with something like this in the docs for the time
functions:
--------------------
All date and time functions, unless otherwise documented, assume the
use of the International Atomic Time (TAI) timescale. TAI differs from
standard time (UTC) in that TAI does not have "leapseconds".
It is likely that the OS clock was set to UTC, not TAI. This slight
difference (22 seconds as of 2000) should not cause any problems unless
date computations of over 6-months with second accuracy are needed.
time() returns the number of seconds elapsed since the beginning of the
International Atomic Time (TAI) timescale, 00:00:00 UTC 1 January 1958.
date($) returns a year-month-day-hour-minute-second representation of
the time passed to it (in seconds since the TAI epoch). The
representation assumes the TAI timescale.
---------------------
>
>
> <chaim>
> --
> Chaim Frenkel Nonlinear Knowledge, Inc.
> [EMAIL PROTECTED] +1-718-236-0183
--
Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice
