[LEAPSECS] Time math libraries, UTC to TAI

[John Sauter]

On Sat, 2017-01-07 at 07:18 -0500, Steve Summit wrote:

> Well, I've concluded I really don't want to put leap seconds
> in the filesystem anyway, for a different set of reasons.
> On leap-second days, clock_gettime(CLOCK_UTC) and
> clock_gettime(CLOCK_REALTIME) necessarily return slightly
> different times.  The legacy calls gettimeofday() and time()
> return whatever CLOCK_REALTIME returns.  And file timestamps
> have to be touched with whatever CLOCK_REALTIME returns, too,
> because Posix says that stat() yields time_t timestamps, and
> legacy code is allowed to fetch the time and touch a file and
> fetch the file's mtime and expect the two timestamps to be nearly
> identical, not to differ by up to a second if smearing is in
> progress.  If you put leap seconds in the filesystem, you have to
> start smearing or unsmearing the timestamps on every stat() call,
> plus you have to have some flag, or different call, by which the
> caller can request whether he wants leapsecond-aware timestamps
> back or not.  Another fine mess, and this one I have no interest
> in tackling.

Perhaps there could be a kernel boot parameter which specified that
CLOCK_REALTIME should act just like CLOCK_UTC.  This would allow brave
souls to work through the problems caused by a fully-UTC kernel,
including EXT4 not storing all 64 bits of a timeval in its mtime, atime
and ctime fields.
    John Sauter (John_Sauter at systemeyescomputerstore.com)
-- 
PGP fingerprint E24A D25B E5FE 4914 A603  49EC 7030 3EA1 9A0B 511E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part
URL: <https://pairlist6.pair.net/pipermail/leapsecs/attachments/20170107/0c6be510/attachment.pgp>