>So the basic problem that POSIX ducked is "should computers keep track of
>mean solar time or count in SI seconds?" The committee's answer seems
>to have been "both". The lack of leap seconds in the time definition
>means that, over long periods of time, they intend to track solar time,
>implying a count in solar seconds. But as they refuse to acknowledge
>the existence of GMT, they mandate use of SI seconds over short periods
>of time, with the effect that a POSIX clock *must*, strictly speaking,
>be discontinuous at leap seconds.
this link: http://tycho.usno.navy.mil/leapsec.html
is a good explanation of the relationship between TAI and UTC.
(they've been doing a lot of maintenance on their server recently,
sometimes it's down)
Previously you had this excerpt from POSIX:
# *Epoch*: Historically, the origin of UNIX system time was referred to as
# "00:00:00 GMT, January 1, 1970." Greenwich Mean Time is actually not a
# term acknowledged by the international standards community; therefore,
# this term, Epoch, is used to abbreviate the reference to the actual
# standard, Coordinated Universal Time. The concept of leap seconds is
# added for precision; at the time POSIX.1 was published, 14 leap seconds
# had been added since January 1, 1970. These 14 seconds are ignored to
# provide an easy and compatible method of computing time differences.
It sounds to me like they're trying to commit to Coordinated
Universal Time (UTC), but can't actually commit to the leap
seconds. What you have then is an entirely new time system
which is essentially Interantional Atomic Time (TAI) offset
from UTC by a fixed amount.
TAI-UTC was calculated at the "POSIX Epoch" as
4.2131700 S + (MJD - 39126) * 0.002592 S
where MJD is the "Modified Julian Date", so we can expect this
number to be somewhere between 4.2 and 10.0
People are generally setting their watches by UTC, and so
this interpretation of POSIX time will diverge from this
over time as more leap seconds are added. Is there anywhere
else in the standard where they actually commit to
recognizing _future_ leap seconds (and tm_sec going 0-60)?
Never mind the 14 they ignore.
Seems odd that they could expect compliant systems to support
leap seconds without specifiying how scheduled future leap
seconds are to be indicated to the system.
- Marsh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu