[tz] What's "right"?

[Paul Eggert]

On 11/12/20 11:50 AM, Steve Allen wrote:

> Pedantically there are no answers which are universally true.

Yes, it's hard to summarize this in a way that's both useful (i.e., brief) and 
true (or at least true enough). I gave it a shot, though, by installing the 
attached proposed patch.
-------------- next part --------------
From 48e68fbfd181f4c23a52021dc27cc45fea75fa25 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert at cs.ucla.edu>
Date: Thu, 12 Nov 2020 12:45:42 -0800
Subject: [PROPOSED] Document "right" seconds better

* tz-link.html (Precision timekeeping):
Clarify "right" vs "posix" time_t.
---
 tz-link.html | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/tz-link.html b/tz-link.html
index 10c40b5..eb4a235 100644
--- a/tz-link.html
+++ b/tz-link.html
@@ -1034,8 +1034,19 @@ title="International Earth Rotation and Reference Systems Service">IERS</abbr>
 Bulletins</a> contains official publications of the International
 Earth Rotation and Reference Systems Service, which decides when leap
 seconds occur. The <code><abbr>tz</abbr></code> code and data support leap seconds
-via an optional "<code>right</code>" configuration, as opposed to the
-default "<code>posix</code>" configuration.</li>
+via an optional "<code>right</code>" configuration where a computer's internal
+<code>time_t</code> integer clock counts every <abbr>TAI</abbr> second,
+as opposed to the default "<code>posix</code>" configuration
+where the internal clock ignores leap seconds.
+The two configurations agree for timestamps starting with 1972-01-01 00:00:00
+UTC (<code>time_t</code> 63 072 000) and diverge for
+timestamps starting with <code>time_t</code> 78 796 800,
+which corresponds to the first leap second
+1972-06-30 23:59:60 UTC in the "<code>right</code>" configuration, and to
+1972-07-01 00:00:00 UTC in the "<code>posix</code>" configuration.
+In practice the two configurations also agree for timestamps before
+1972 even though the historical situation is messy, partly because
+neither UTC nor TAI is well-defined for sufficiently-old timestamps.</li>
 <li><a href="https://developers.google.com/time/smear">Leap Smear</a>
 discusses how to gradually adjust <abbr>POSIX</abbr> clocks near a
 leap second so that they disagree with <abbr>UTC</abbr> by at most a
-- 
2.25.1