In message <[EMAIL PROTECTED]>, 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 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
