[lkml]   [2009]   [Jan]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Bug: Status/Summary of slashdot leap-second crash on new years 2008-2009
    On Tue, Jan 06, 2009 at 12:29:47PM +1030, David Newall wrote:
    > Nick Andrew wrote:
    > > I can sympathise with the opinion that linux should be able to accurately
    > > distinguish xx:59:60 when a leap second is added (or the missing :59 when
    > > one is subtracted) but not at the expense of making a day which is not
    > > 86400 seconds long.
    > >
    > Some days are not 86400 seconds long. That's a fact and regardless of
    > how inconvenient it is, we have to live with it.

    Sorry, but you're wrong - in the context of time_t, every day is 86400
    seconds long. man 2 time says so clearly in the notes:

    POSIX.1 defines seconds since the Epoch as a value to be interpreted as the number of sec‐
    onds between a specified time and the Epoch, according to a formula for conversion from
    UTC equivalent to conversion on the naive basis that leap seconds are ignored and all
    years divisible by 4 are leap years. This value is not the same as the actual number of
    seconds between the time and the Epoch, because of leap seconds and because clocks are not
    required to be synchronized to a standard reference.

    > Some years don't have
    > 365 days; some months don't have 30 days; some Februaries don' have 28
    > days; and now, some days don't have 86400 seconds. What's the point in
    > fighting this?

    I'm not fighting this - the real world has all these issues but the
    world of time_t does not. You want to redefine time_t to include all
    the leap seconds that were already added (34) or perhaps only the
    future ones; either approach is a disaster. It's unreasonable to change
    the semantics of something as fundamental as time_t when so much code
    depends on those semantics.

    Instead, define a new timebase which counts time predictably and
    unambiguously then a set of mappings to derived time values like
    time_t, UTC and local time.

    > > Just so long as the
    > > existing behaviour of time() which doesn't recognise leap seconds
    > > is preserved.
    > I haven't been able to find this Annex B that Alan talked of, so I can
    > only go by the man page, which states, simply and explicitly, that
    > time() returns seconds since Epoch, and also that Epoch is start of
    > January 1 1970. To my mind, time *does* recognise leap seconds.

    Please read the NOTES section, which clarifies what "seconds since
    the Epoch" means.

    PGP Key ID = 0x418487E7
    PGP Key fingerprint = B3ED 6894 8E49 1770 C24A 67E3 6266 6EB9 4184 87E7
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2009-01-06 03:55    [W:0.023 / U:18.600 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site