[LEAPSECS] Time math libraries, UTC to TAI

[Steve Summit]

Warner wrote:
> On Wed, Jan 4, 2017 at 9:26 PM, Steve Summit <scs+ls at eskimo.com> wrote:
> > Warner Losh wrote:
> >> 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?

All times are stored in the inode in UTC, and (per Posix) are
reported by stat() in UTC.  I'm really not sure why you're even
suggesting the possibility of converting to/from TAI here.

(I've seen occasional suggestions of storing TAI in the inode,
but it's clearly a terrible idea, that would impose ruinous
conversion requirements and introduce nightmarish compatibility
conflicts.)

> 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...

Keeping kernel time in TAI is a separate question from what
clock_gettime(CLOCK_REALTIME) reports, which is of course a
separate question from what clock_gettime(CLOCK_UTC) reports.

I mentioned the possibility of keeping TAI in the kernel as one
point along a spectrum of options in support of being able to
accurately report CLOCK_UTC at all.  By itself it clearly doesn't
do anything to solve the problem of mapping UTC onto time_t.
But as a separate piece of the puzzle I'm also smearing
CLOCK_REALTIME across leap seconds (that is, in the process of
deriving CLOCK_REALTIME from whatever modified internal clock
I'm using) so that it never jumps or runs backwards.