[lkml]   [1998]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Y2K
       From: Zefram <>
    Date: Tue, 23 Jun 1998 11:30:02 +0100 (BST)

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

    Actually, what I see this as is that tm_sec, tm_min, tm_hour,
    et. al. don't exactly correspond to the seconds, minutes, and hours as
    measured by UTC. So "real time" might be 15:04:14, but tm_sec will be
    14 seconds different from "real time". Seconds since the epoch are
    indeed still "seconds since the epoch" --- and regardless of whatever
    else we did, that definition was probably the correct one. We want the
    time returned by time(0) to be a monotonically increasing number that
    doesn't deal with slipping a second to deal with leap seconds.

    The questionable decision at least in my mind is the translation between
    "seconds since the Epoch" and struct tm. The POSIX definition ignores
    leaps seconds when defining the conversion. It probably would have been
    a better idea to take leap seconds into account when doing time
    conversions, although this does cause other problems, such as different
    Unix systems doing different things depending on when the system was
    last updated (the Time standards folks only give roughly 6 months
    warning or less before adding or removing a leap second); so unless you
    keep your Unix machine constantly up to date, your ctime() may return a
    different result from your neighbor's ctime(), depending on when the
    leap second table on your machine was last updated. Presumably the
    POSIX people decided this was too horrible, and decided to punt on the

    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

    I agree that this wasn't their finest hour, but there really isn't a
    good solution to this problem. Their solution is self-consistent and
    well defined, IMO. To quote their rationale, "it is important that all
    conforming systems interpret "536 457 599 seconds since the Epoch" as 59
    seconds, 59 minutes, 23 hours 31 December 1986". If this is the goal
    (and there are valid reasons for that goal --- take for example network
    protocols that send times around as "19861231235959Z") then their
    solution is the only valid one, given that when leap seconds occur is
    not predictable more than a few months in advance.

    - Ted

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