Messages in this thread | | | From | "Marsh Ray" <> | Subject | Re: Y2K | Date | Thu, 25 Jun 1998 17:12:47 -0400 |
| |
From: Zefram <zefram@tao.co.uk>
>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
| |