Thanks for the review. Attached is a proposed patch that attempts to
address your comments, except that I didn't understand this remark:
3.Leap second records definition
How 64 bit data block can be used to accommodate 16 octet records?
The draft doesn't mention 16-octet records, so I'm not sure what this
comment is referring to. A leap second record is 8 octets in the 32-bit
data block, and is 12 octets in the 64-bit data block. The difference in
length is because the former uses a 4 octet 'occur' field whereas the
latter uses 8. The 'corr' field is always a 4-octet value, because it's
assumed that the leap second correction (which is a relative time, not
an absolute time) must fit into a 32-bit signed integer. In hindsight
perhaps the leap second correction should also have been an 8-octet
value, as the 4-octet value will stop working many thousands of years
from now (see <https://www.ucolick.org/~sla/leapsecs/dutc.html> for why)
whereas an 8-octet value would have been more future-proof. However,
billions of readers already assume 4-octet leap second corrections so
we'll have to defer fixing this to a later version of TZif. Most likely
version 3 will be obsolete for other reasons long before the limited
'corr' range becomes a real problem. (If you think this issue should be
discussed in the spec, I can add something; just let me know.)
The attached proposed patch assumes an earlier patch
<https://www.ietf.org/mail-archive/web/tzdist-bis/current/msg00339.html>
that I proposed in response to Tom Petch's review.
--- draft-murchison-tzdist-tzif-14-01.xml 2018-09-13 11:27:43.484884588 -0700
+++ draft-murchison-tzdist-tzif-14-02.xml 2018-09-27 08:11:16.386765915 -0700
@@ -162,6 +162,10 @@
The time according to a location's current time zone
offset from Universal Time.
</t>
+ <t hangText="POSIX Epoch:">
+ 1970-01-01 00:00:00 UTC, the basis for absolute timestamps
+ in this document.
+ </t>
<t hangText="Standard Time:">
The time according to a location's law or practice,
unadjusted for Daylight Saving Time.
@@ -185,6 +189,11 @@
time zone abbreviations." The interchange format defined in
this document is one such form of time zone data.
</t>
+ <t hangText="Transition Time:">
+ The moment of occurrence of a time change that is not a leap
+ second. It is identified with a signed integer count of
+ Unix Leap Time seconds since the POSIX Epoch.
+ </t>
<t hangText="Universal Time (UT):">
The basis of civil time.
This is the principal form of the mean solar time at the
@@ -201,7 +210,7 @@
target="http://pubs.opengroup.org/onlinepubs/9699919799/functions/time.html";>
Section 3 of the "System Interfaces" Volume</eref> of <xref
target="POSIX"/>). This is an integer number of seconds
- since the POSIX Epoch (1970-01-01 00:00:00 UTC) not counting
+ since the POSIX Epoch, not counting
leap seconds. As an extension to POSIX, negative values
represent times before the POSIX Epoch, using UT.
</t>
@@ -233,7 +242,10 @@
variable-length <xref target='data'>data block</xref> using
four-octet (32-bit) transition times and leap second
occurrences. These 32-bit values are limited to representing
- times from 1901-12-13 20:45:52 through 2038-01-19 03:14:07 UT.</t>
+ time changes from 1901-12-13 20:45:52 through 2038-01-19 03:14:07 UT,
+ and the initial header and data block are present only for backward
+ compatibility with obsolescent readers as discussed in
+ <a xref='issues'>Common Interoperability Issues</a>.</t>
<t>The TZif header contains a field which specifies the version
of the file's format. Version 1 files terminate after the
@@ -385,6 +397,11 @@
</t>
</list>
</t>
+
+ <t>Although the 32- and 64-bit headers have the same format
+ with the same magic number and version fields, their count
+ fields can differ because the 32-bit data can be a subset of
+ the 64-bit data.</t>
</section> <!-- header -->
<section anchor='data' title='TZif Data Block'>
@@ -671,6 +688,10 @@
</list>
</t>
+ <t>The TZif footer is present only in Version 2 and 3 files,
+ as the obsolescent Version 1 format was designed before the
+ need for a footer was apparent.</t>
+
<section anchor='tzstrext' title='TZ String Extensions'>
<t>The TZ string in a Version 3 TZif file MAY use the
following extensions to POSIX TZ strings.
