[LEAPSECS] Time math libraries, UTC to TAI

[Warner Losh]

On Wed, Jan 4, 2017 at 9:26 PM, Steve Summit <scs+ls at eskimo.com> wrote:
> Warner Losh wrote:
>> On Wed, Jan 4, 2017 at 7:15 PM, Steve Summit <scs+ls at eskimo.com> wrote:
>> > 2. Have xtime keep TAI.  This has the advantage that it's not at
>> >    all wrong or kludgey to represent TAI as a simple count of
>> >    seconds since the epoch, which of course xtime already is.
>>
>> The problem here, not listed, is with external stuff. When I touch
>> a file, the time needs to be stored in UTC time so TAI needs to be
>> converted to UTC
>
> Sure.  But it's a given that if we keep TAI internally, we have
> a way to easily convert it to UTC any time anybody asks for it.
> So we do the same conversion any time we need an updated
> timestamp for a file.  In general, every updated file timestamp
> comes from the equivalent of clock_gettime(CLOCK_UTC) /
> getimeofday() / time().

That just requires one number: the current offset.

>> and back again when dealing with files on disk.
>
> Not sure what you mean there.

Internally, the kernel is keeping time in TAI. So when the time is
updated in the inode, you have to do a TAI to UTC conversion.

>> It then becomes an interesting question: do you have to back convert
>> form UTC to TAI when doing a stat on a file in this scheme?
>
> No, not at all.  The timestamp in the inode on disk was stored in
> UTC, as it always has been.

Right, and is the time_t in the st_atime, st_mtime and st_ctime fields
reported as UTC or TAI? If TAI, you need a table and an agreed
convention for dates prior to 1972.

But keeping the kernel time in TAI and reporting it in UTC still
doesn't solve the userland side of things because time goes backwards
across the leap second... If everything were in TAI and it was just a
conversion, then some math with time breaks.

Warner