[lkml]   [1998]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: GPS Leap Second Scheduled!
    > Hence, the above equation would have the same value for 23:59:60 and
    > 00:00:00 on the next day. Hence, time() should return the same value.

    The problem becomes more acute for gettimeofday() and the POSIX
    ns-resolution equivalent, clock_gettime(CLOCK_REALTIME).

    There are a few axioms that you'd like to have hold:

    - time() and gettimeofday() return the same time as
    clock_gettime(CLOCK_REALTIME), as far as precision permits.
    - gettimeofday() never returns the same value twice (documented BSD behaviour)
    - no clock ever runs backwards

    This makes the handling of the tv_usec or tv_nsec parts of the time during
    a leap second a bit problematic.

    One option is to count twice.
    One option is to count at half speed during 23:59:60 and 0:00:00.
    One option is to use the curve y = 1/4*x^3 - 3/4*x^2 + x to interpolate
    y smoothly from 0 to 1 as x goes from 0 to 2.
    One option is to freeze the fractional part fr one of the two seconds.
    One (pretty rude) option is to count tv_usec from -1000000 to -1
    during 23:59:60. (tv_usec is a *signed* long.)

    I don't know of a pretty way. What I'd like, as I said, is a defined kludge,
    so that there is a defined mapping between struct timeval and struct timespec
    and UTC in the vicinity of a leap second. This ensures that timestamps
    collected on different machines can at least be compared, even if the
    time intervals reported are incorrect. ("Why were my ping times
    half of usual at midnight last night?")

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

     \ /
      Last update: 2005-03-22 13:44    [W:0.031 / U:2.508 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site