[LEAPSECS] Time math libraries, UTC to TAI

[Zefram]

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.  The library must handle the nanoseconds
decoding in order to insulate the user from this detail.

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

>*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, glibc/Linux struct
stat has

	struct timespec st_atim;
	#define st_atime st_atim.tv_sec

but depending on preprocessor flags it may instead compile

	__time_t st_atime;
	__syscall_ulong_t st_atimensec;

Either way the name "st_atime" is supported; the newer "st_atim" is
conditionally supported.

There's also some support at the syscall interface for different layouts
of struct stat: there are different syscall numbers for different versions
of struct stat.  Historically that was needed to increase the size of
st_size, st_uid, the integral parts of the timestamps, and some other
fields, but the presence of nanoseconds in struct stat seems to go back
much further.  I can't find a Linux version of the structure that doesn't
have nanoseconds.

glibc also has some logic to mediate between the version of struct stat
that a program was compiled with and the versions supported by the kernel.
The linkage games that it plays allow for types and structure layouts
to safely change quite independent of the kernel support.  This is the
mechanism you'd need to compatibly add tm_nsec to struct tm.

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

That might be interpreted as a profligate use of inode bits.  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.

-zefram