[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.021 / U:26.600 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site