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 ([email protected])
--
PGP fingerprint E24A D25B E5FE 4914 A603 49EC 7030 3EA1 9A0B 511E
signature.asc
Description: This is a digitally signed message part
_______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
