[lkml]   [1998]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Y2K
Alan Cox wrote:
>Has POSIX yet determined what sort of second since the Epoch ?

POSIX.1, clause

# The time() function returns the value of time in seconds since the Epoch.


# *Epoch*: The time 0 hours, 0 minutes, 0 seconds, January 1, 1970,
# Coordinated Universal Time.
# See seconds since the Epoch.


# *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

(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.)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to

 \ /
  Last update: 2005-03-22 13:43    [W:0.039 / U:9.468 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site