On 09/04/2013 03:29 PM, H. Peter Anvin wrote:
> On 09/04/2013 01:54 PM, John Stultz wrote:
>>> 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.
> Not so (see below).
>
>> 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.
>>
> But not fractional-second information,right? I believe it would be
> desirable if we can create a small structure (<= 16 bytes) for this.
Well, depending on if STA_NANO is set, adjtimex returns either nsec or
usec precision via the timex.time field.
> UTC - TAI is always an integral number of seconds, possibly negative
> (unlikely, but...)
>
> Something like:
>
> struct time_ns {
> u64 tai_s;
> u32 tai_ns;
> s16 utcdelta; /* TAI - UTC */
> u8 leap; /* Positive leap second in progress */
> u8 pad; /* Something useful here maybe? */
> };
>
> Why the leap second flag? It is necessary to represent the 61st second
> in a minute during a positive leap second. Consider the below
> (artificial) cases:
>
> (leap second)
> TAI 31536000 31536001 31536002 31536003
> Delta 2 2 ? 3
> UTC 23:59:58 23:59:59 23:59:60 00:00:00
>
> (no leap second)
> TAI 31536000 31536001 31536002 31536003
> Delta 2 2 2 2
> UTC 23:59:58 23:59:59 00:00:00 00:00:01
>
> (no leap second)
> TAI 31536000 31536001 31536002 31536003
> Delta 3 3 3 3
> UTC 23:59:57 23:59:58 23:59:59 00:00:00
>
> There simply is no sufficiently meaningful value that can be put on the
> delta during a positive leap second. Both 2 and 3 would be wrong in the
> above example, giving UTC of either 00:00:00 or 23:59:59.
>
> There is a way to do without the leap second flag by making UTC the main
> time; this does have the advantage of higher compatibility with time_t,
> struct timespec, etc:
>
> struct timespecx {
> time_t tx_sec; /* POSIX UTC seconds */
> u32 tx_ns; /* Nanoseconds */
> s32 tx_taidelta; /* TAI - UTC */
> };
And again, most of the detail above is already there w/ adjtimex (though
admittedly not in a very tight format).
My concern with adding these details to the timespec-like structure this
is with most clockids I'm not sure taidelta would make sense.
Also, there's been talk of a slewed-leap-second clockid, basically UTC
but around the leapsecond it slows down to absorb the extra second. This
means that clockid would have a subsecond offset from TAI.
thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
