[LEAPSECS] Time math libraries, UTC to TAI

[Steve Summit]

zefram wrote:
> Steve Summit wrote:
>> Hoo, boy.  I would love to, but that's a project for another day,
>> and has nothing directly to do with leap seconds.
>
> It's pretty relevant to the way you're encoding leap seconds in struct
> timespec.  If your gmtime_ts_r() doesn't produce a tm_nsec output,
> then any caller interested in the nanoseconds needs to extract it from
> the struct timespec emself, and thus needs to know about the irregular
> encoding therein of leap seconds.

I know exactly what you mean; in fact -- true confession --
the very first time I tested my brand-new kernel and brand-new
gmtime_ts_r across a simulated leap second, I forgot to do that
tricky and non-obvious handling in my top-level calling code,
leading to a goofy bug.

Okay, so maybe I'll bump the priority of tm_nsec.

>> if struct tm had tm_nsec, what should strftime do with it?
>
> I'd expect strftime() to adopt the %N format specifier from GNU date(1).

An obvious choice, which I'm personally less than fond of.  It's
great for printing human-readable nanoseconds, but if you want to
print milliseconds or microseconds, you have to extract it and
manipulate it yourself.

>> *Interfaces*?  Really?  Struct stat64, maybe, but struct stat
>> can't, without breaking backwards compatibility.  (Unless it's
>> playing tricky games with unions or something.)
>
> It is playing tricky games.  At the source level...
> but depending on preprocessor flags...
> There's also some support at the syscall interface for different layouts...
> glibc also has some logic to mediate...
> The linkage games that it plays allow...
> This is the mechanism you'd need to compatibly add tm_nsec to struct tm.

Oh, my.  I knew about some of that, suspected a few other bits,
but was blissfully unaware of the rest.

(Anybody know of a, like, college-level course anywhere on this
stuff?  I despair of ever reverse-engineering it all...)

>> To extend the *range*?  What's wrong with just making tv_sec
>> (like time_t) 64 bits, which is happening everywhere else anyway?

(That was a rhetorical question, of course.)

> That might be interpreted as a profligate use of inode bits.

Yeah, especially since the promised zettabyte drives are still
nowhere in sight, and we're all having to make do with these
cramped old terabyte ones.

> I'd probably have gone straight to 64 integral bits if it had been my
> decision, but one can see why saving four bytes per inode for another
> two centuries would be an attractive choice.

Oh, yeah, I can see why; I just wouldn't have *liked* it.