Messages in this thread | | | From | Zefram <> | Subject | Re: Y2K | Date | Tue, 23 Jun 1998 11:30:02 +0100 (BST) |
| |
Alan Cox wrote: >Has POSIX yet determined what sort of second since the Epoch ?
POSIX.1, clause 4.5.1.2:
# The time() function returns the value of time in seconds since the Epoch.
Clause 2.2.2.36:
# *Epoch*: The time 0 hours, 0 minutes, 0 seconds, January 1, 1970, # Coordinated Universal Time. # # See seconds since the Epoch.
Clause 2.2.2.113:
# *seconds since the Epoch*: A value to be interpreted as the number of # seconds between a specified time and the Epoch. # # A Coordinated Universal Time name (specified in terms of seconds (tm_sec), # minutes (tm_min), hours (tm_hour), days since January 1 of the year # (tm_yday), and calendar year minus 1900 (tm_year) is related to a time # represented as seconds since the Epoch according to the expression below. # # If the year < 1970 or the value is negative, the relationship is # undefined. If the year >= 1970 and the value is nonnegative, the value is # related to a Coordinated Universal Time name according to the expression: # # tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + # (tm_year-70)*31536000 + ((tm_year-69)/4)*86400
This unambiguously is *not* literally "seconds since the Epoch"; it is the number of seconds since the Epoch minus the number of leap seconds since the Epoch. The Rationale (clause B.2.2.2) is illuminating:
# *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.
[Tr: GMT does not have leap seconds, so the POSIX time definition does not count UTC's leap seconds, so that a numerical time_t will have the same struct tm breakdown under either definition. The actual times represented under these two interpretations, GMT and UTC, can drift up to 0.9s apart -- GMT and UTC, by their definitions, have differing lengths of seconds, with leap seconds being inserted into UTC to keep them in step.]
[The next few paragraphs give lengthy and arguably contradictory statements about this definition being good enough. Looks like there was some disagreement amoung the committee.]
# Note that the expression given will fail after the year 2099. Since the # issue of time_t overflowing a 32-bit integer occurs well before that time, # both of these will have to be addressed in revisions to POSIX.1.
[So a Y2.1K problem in POSIX.1. This would seem to limit how time-independent a POSIX OS can be.]
My take on this is that it is not the POSIX committee's finest hour. They have, as usual, examined the various poorly-specified systems in common use, invented a compromise that satisfies no one, and been unsurprisingly unable to write it up as a logical and self-consistent standard.
(The time standard I'd really like to see would be strictly SI seconds since the TAI epoch, 1958-01-01, and let the library handle the complications of displaying times in UTC notation. But this is not the right standard for a Unix-like OS.)
-zefram
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |