On 09/04/2013 01:33 PM, Andy Lutomirski wrote: > On Wed, Sep 4, 2013 at 12:20 PM, John Stultz <[email protected]> wrote: >> On Wed, Sep 4, 2013 at 11:51 AM, Andy Lutomirski <[email protected]> wrote: >>> I think that most of the hangup was a lack of agreement on how the API >>> should work wrt leap seconds. >> I don't recall this objection. The interface uses existing clockids, >> so it probably should keep the existing leap-second behavior of those >> clockids. >> >>> I've always thought that the Right Way to represent a UTC time is >>> nanoseconds since some epoch, where every potential leap second >>> counts. >> Check out the CLOCK_TAI clockid merged in 3.10. >> > I never really liked that -- CLOCK_TAI doesn't tell what time it is in > any format that normal people understand. > > I'd advocate for going whole hog and returning, atomically: > > - TAI (nanoseconds from epoch) > - UTC - TAI (seconds or nanoseconds) * > - TAI - CLOCK_MONOTONIC (nanoseconds) > - a leap second flag. > > * There are various ways to define this. My fancy UTC - TAI wouldn't > actually need the leap-second flag, since the UTC time would indicate > leap seconds directly. With the conventional approach, someone would > have to decide whether the leap second count increments at the > beginning or the end of the leap second.
Well, adjtimex() gives you UTC & tai offset & leapsecond flag in one go. thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
