Re: [Scheme-reports] current-posix-second is a disastrous mistake Thomas Bushnell, BSG (17 Dec 2010 23:55 UTC)
Re: [Scheme-reports] current-posix-second is a disastrous mistake John Cowan (18 Dec 2010 04:19 UTC)

Re: [Scheme-reports] current-posix-second is a disastrous mistake John Cowan 18 Dec 2010 04:18 UTC

Thomas Bushnell, BSG scripsit:

> Posix should never have done what they did. But they did it, and now there
> is a serious problem if Scheme diverges.

Well, here's what Wikipedia says about what happened in the committee:

[T]he Unix time scale was originally intended to be a simple linear
representation of time elapsed since an epoch. However, there was no
consideration of the details of time scales, and it was implicitly
assumed that there was a simple linear time scale already available and
agreed upon. Indeed, the first edition manual's definition doesn't even
specify which timezone is used. Several later problems, including the
complexity of the present definition, result from Unix time having been
defined gradually by usage rather than fully defined to start with.

When POSIX.1 was written (it was published in 1988), the question arose
of how to precisely define time_t in the face of leap seconds. Some argued
for it to remain, as intended, a linear count of seconds since the epoch,
at the expense of complexity in conversions with civil time. Others argued
for it to remain, as conflictingly intended, easily interconvertible
with the conventional representation of civil time, at the expense of
inconsistency around leap seconds. Computer clocks of the era were not
sufficiently precisely set to form a precedent one way or the other.

The POSIX committee was swayed by arguments against complexity in the
library functions, and firmly defined the Unix time in a simple manner
in terms of the elements of UTC time. Unfortunately, this definition
was so simple that it didn't even encompass the entire leap year rule
of the Gregorian calendar, and would make 2100 a leap year.

The 2001 edition of POSIX.1 rectified the faulty leap year rule in the
definition of Unix time, but retained the essential definition of Unix
time as an encoding of UTC rather than a linear time scale. Also, since
the mid-1990s computer clocks have been routinely set with sufficient
precision for this to matter, and they have most commonly been set using
the UTC-based definition of Unix time. This has resulted in considerable
complexity in Unix implementations, and in the Network Time Protocol,
to execute steps in the Unix time number whenever leap seconds occur.

--
I could dance with you till the cows            John Cowan
come home.  On second thought, I'd              http://www.ccil.org/~cowan
rather dance with the cows when you             cowan@ccil.org
come home.  --Rufus T. Firefly

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports