In message <20050809135121.GA9297_at_ucolick.org>, Steve Allen writes:
>On Tue 2005-08-09T11:57:01 +0200, Poul-Henning Kamp hath writ:
>> For some reason, the acronym POSIX comes to mind :-)
>
>The POSIX time_t corresponds quite well to the way that civil time has
>been maintained throughout history. I doubt that POSIX could have
>done anything with time_t other than to supplement it with an
>interface which was designed with uniform time in mind.
POSIX made most if its mistakes because they were backward and
vendor focused, trying to make certain that every (major) vendors
operating system would be compatible, rather than beeing forward
and user oriented and look to what the users would need for the
next decades. (This is what is called a "rubber-stamp-standard").
For these internal reasons they couldn't have done anything about
time_t, even if they had wanted to. If they had wanted to, and if
they had been forward looking, they would have put leapseconds into
the time_t timescale (since abandoning leap-seconds were not in
their power).
The fact that DoD now realizes that it is easier to get TF-460
changed than getting POSIX changed is a sign of sound fiscal
responsibility on their part but a damning testament to the
intellectual bancruptcy of the UNIX industry.
>Warner Losh has written to me about the references to FreeBSD in my
>online bibliography. It is still not clear what FreeBSD actually
>does with leap seconds, or whether the online documentation is
>obsolete.
FreeBSD does what every other NTP synchronizable POSIX compliant
operating does: Rerun the last (time_t) second of the day once
again during the leapsecond.
Thanks to a cute definition of the mktime() library call, if you
enter a true leapsecond timestamp (23:59:60), you will not get
the last second of the day but rather the first second of the
following day. (This is also POSIX spec, so it can't be changed).
So anyone using a POSIX system to calculate a timedifference relative
to an externally generated correct UTC leapsecond timestamp would
get an error of not just one but up to two seconds.
>No doubt there are a lot of other folks thinking of changes to their
>leap second handling code in anticipation of the end of December.
The best thing we can say about this next leap second is that it
gives us the chance to determine the actual economical cost of
leapseconds.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
Received on Tue Aug 09 2005 - 08:22:24 PDT