lkml.org 
[lkml]   [2009]   [Jan]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [ntpwg] Bug: Status/Summary of slashdot leap-second crash on new years 2008-2009
    On Wed 2009-01-07T10:39:47 -0700, M. Warner Losh hath writ:
    > The suggestion to solving this would be to tick in TAI time, and force
    > userland to cope with the leapsecond issues. Of course, there's a
    > number of problems with this solution as well, but it feels like it
    > belongs there...

    Agreed that the leap second belong in userland, but BIPM itself
    refuses to agree with the idea of the underlying time scale being TAI.
    TAI has no standing as an international recommendation, and it is not
    available via the established broadcast mechanisms, and BIPM does not
    want those things to happen. What would be needed is a leap-free time
    scale with an international recommendation standing behind it so as to
    legitimize its use.

    The most recent public insight to the ITU-R process of reconsidering
    leap seconds in UTC is from September, here
    http://www.navcen.uscg.gov/cgsic/meetings/48thmeeting/Reports/Timing%20Subcommittee/48-LS%2020080916.pdf
    In the schedule given on page 16 we see that even if the ITU-R process
    goes smoothly there will be leap seconds at least until 2017, so we
    have to live with them for at least that long. However, at the
    October meeting of ITU-R WP7A things did not go smoothly. There were
    two countries objecting to any change to UTC, so the process of
    considering any change to the broadcast time scale is stalled.

    Basically, any change to UTC is currently stalled by the
    international political/diplomatic process which controls it.

    Way back in 2003 the ITU-R asked for advice on the broadcast time
    scale, and the advice from the experts included changing the name if
    leaps are dropped.
    http://www.inrim.it/luc/cesio/itu/closure.pdf
    At that point nobody managed to point out that POSIX demands that the
    zoneinfo mechanisms allow for offsets of seconds as well as minutes,
    so there was no clear path for implementing that advice while
    preserving compliance with specifications that still demand UTC.

    Any epoch-based time scale has issues with UTC as it has been defined
    http://www.ucolick.org/~sla/leapsecs/epochtime.html
    and by ignoring leap seconds POSIX makes that even harder to implement.
    During the past century we have seen the creation of at least 4
    different uniform time scales, two of which are widely available by
    broacast (LORAN-C and GPS), but none of which has the backing of an
    international standard behind it.
    http://www.ucolick.org/~sla/leapsecs/deltat.html

    All civil time scales are conventional constructs, and zoneinfo is
    designed to handle the arbitrary nature of changes to civil time. If
    the underlying time scale changes its name and stops having leaps,
    then leap seconds in UTC are just another form of conventional change
    to civil time. UTC could become a time zone. Processes which happen
    when POSIX time_t % 86400 == 0 would happen at "atomic midnight"
    instead of "civil" midnight, not a big difference.

    If the ITU-R were to take the advice of the colloquium it organized,
    if they were to abandon the name UTC, and establish a new
    international broadcast time scale with a new name, then the
    operational systems of the world receiving those broadcasts would not
    notice. There would be some rewriting of documents, specifications,
    and some extra work streamlining zoneinfo.

    It's not just an engineering tradeoff, it's a political tradeoff.
    The question for the NTP implementors, kernel hackers, application
    writers is whether it's worth waiting to see if the current political
    impasse about UTC can be broken, or whether it seems better, easier,
    and quicker to lobby the ITU-R delegations to abandon the name UTC
    and give a new name to a broadcast time scale without leaps.

    Either way we will have to handle another decade of leap seconds
    before the broadcast time scale can change its characteristics.

    replies directed to the LEAPSECS list

    --
    Steve Allen <sla@ucolick.org> WGS-84 (GPS)
    UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855
    University of California Voice: +1 831 459 3046 Lng -122.06015
    Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m


    \
     
     \ /
      Last update: 2009-01-08 21:41    [W:0.042 / U:0.440 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site