[tz] [PROPOSED] Match RFC 8536bis-01 better

[Paul Eggert]

* NEWS: Mention this.
* tzfile.5: The draft RFC 8536bis-01 came out today;
match its wording better.
---
 NEWS     |  5 +++++
 tzfile.5 | 20 +++++++++++---------
 2 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/NEWS b/NEWS
index 00dea3c..e5f5e90 100644
--- a/NEWS
+++ b/NEWS
@@ -182,6 +182,11 @@ Unreleased, experimental changes
     non-POSIX hosts where malloc doesn't set errno.
     (Problem reported by Jan Engelhardt.)
 
+  Changes to documentation
+
+    tzfile.5 better matches a draft successor to RFC 8536
+    <https://datatracker.ietf.org/doc/draft-murchison-rfc8536bis/01/>.
+
 
 Release 2021a - 2021-01-24 10:54:57 -0800
 
diff --git a/tzfile.5 b/tzfile.5
index b1932bd..dd42660 100644
--- a/tzfile.5
+++ b/tzfile.5
@@ -152,13 +152,14 @@ Each pair denotes one leap second, either positive or negative,
 except that if the last pair has the same correction as the previous one,
 the last pair denotes the leap second table's expiration time.
 Each leap second is at the end of a UTC calendar month.
-The first leap second is positive if and only if its correction is positive,
-and the correction for each leap second after the first differs
+The first leap second has a nonnegative occurrence time,
+and is a positive leap second if and only if its correction is positive;
+the correction for each leap second after the first differs
 from the previous leap second by either 1 for a positive leap second,
 or \-1 for a negative leap second.
 If the leap second table is empty, the leap-second correction is zero
 for all timestamps;
-otherwise, for timestamps before the first correction time,
+otherwise, for timestamps before the first occurrence time,
 the leap-second correction is zero if the first pair's correction is 1 or \-1,
 and is unspecified otherwise (which can happen only in files
 truncated at the start).
@@ -255,11 +256,12 @@ any data that extends beyond the calculated end of the version
 .PP
 Other than version 1, writers should generate
 the lowest version number needed by a file's data.
-For example, a writer should generate a version 3 file
-if its leap second table neither expires nor is truncated at the start
-and so does not use version 4 features, but
+For example, a writer should generate a version 4 file
+only if its leap second table either expires or is truncated at the start.
+Likewise, a writer not generating a version 4 file
+should generate a version 3 file only
 TZ string extensions are necessary to accurately
-model transition times so the file does need version 3 features.
+model transition times.
 .PP
 The sequence of time changes defined by the version 1
 header and data block should be a contiguous sub-sequence
@@ -433,9 +435,9 @@ abbreviations correctly.
 Some readers generate ambiguous timestamps for positive leap seconds
 that occur when the UTC offset is not a multiple of 60 seconds.
 For example, in a timezone with UTC offset +01:23:45 and with
-a positive leap second 78796801 (1972-06-30 23:59:60 UTC), they
+a positive leap second 78796801 (1972-06-30 23:59:60 UTC), some readers will
 map both 78796800 and 78796801 to 01:23:45 local time the next day
-instead of mapping the latter to 01:23:46, and they map 78796815 to
+instead of mapping the latter to 01:23:46, and they will map 78796815 to
 01:23:59 instead of to 01:23:60.
 This has not yet been a practical problem, since no civil authority
 has observed such UTC offsets since leap seconds were
-- 
2.30.2