Re: [Scheme-reports] current-posix-second is a disastrous mistake

[Taylor R Campbell <campbell+scheme@x>]

   Date: Wed, 15 Dec 2010 12:09:47 +0200
   From: Vitaly Magerya <vmagerya@x>

   In short, as long as UTC is the basis of civil time keeping, TAI will
   not solve any problems.

A UTC clock ticks seconds on exactly the same intervals that a TAI
clock does.  Whether you say SECONDS-SINCE-UTC-EPOCH returns the
number of UTC clock seconds since the UTC epoch or the number of TAI
clock seconds since the UTC epoch makes no difference.  It's the POSIX
clock that's wrong.

   [1] To be clear on this, NTP does not transmit current UTC-TAI
   difference by default. There is in fact "tai" field in ntptimeval,
   but it is only updated by ntpd if it has a leap seconds table....

Not quite.  Within 86400 seconds before a leap second, an NTP server
raises a flag alerting clients of the pending leap second.  At the
start of the leap second, the NTP's wire format for times shifts by
one second, and simultaneously the flag lowers.  Clients can thereby
see a smooth view of TAI/UTC time.

Linux, NetBSD, and FreeBSD all have a variable time_tai that is
incremented at the moment the leap second ends and the POSIX clock is
set back by a second.  The userland can request the value of time_tai
through ntp_gettime (BSD) or adjtimex/ntp_adjtime (Linux).  Programs
can thereby see a smooth view of TAI/UTC time.

(Putting any calendrical logic (e.g., leap seconds) in the kernel's
timekeeping is asinine, of course, but traditional.)

time_tai is initialized correctly only if the userland (e.g., the
ntpd) initializes it correctly with ntp_adjtime.  But if it is not
initialized thus, you will still see a smooth view of TAI/UTC time.
At worst, your calendar may display dates that are off by up to half a
minute.  Do you care?  Probably not.  If you did, you would have told
your system about the historical leap second table.

Why do we care about a smooth view of TAI/UTC time and not just
`monotonic time'?  Because two different computers can agree on the
UTC epoch but not on a boot-time epoch for a monotonic clock.

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports