Subject: [Tzdist-bis] timestamps before first and after last transition, etc.

From: Paul Eggert <[email-masked]>
Date: Tue, 29 May 2018 07:42:22 -0700

This comment is inspired by the seemingly-weird "MUST NOT" in the "typecnt" 
definition. It turns out that there's a good reason for the "MUST NOT", that 
current clients widely rely on the "MUST NOT", and that we should document the 
reason why, which has to do with timestamps before the first transition (what 
type of time are they?). While we're at it, there's a lesser problem with 
timestamps after the last transition. Plus, the draft never clearly specifies 
that a transition specifies time types for all timestamps up to (but not 
including) the next transition time, so let's fix that too.

Proposed patch attached.
--- draft-murchison-tzdist-tzif-02.txt	2018-05-24 08:55:16.000000000 -0700
+++ draft-murchison-tzdist-tzif-02-fix.txt	2018-05-29 07:41:06.238773223 -0700
@@ -341,7 +341,7 @@
         +---------------------------------------------------------+
         |  transition times          (timecnt x TIME_SIZE)        |
         +---------------------------------------------------------+
-        |  transition time index     (timecnt)                    |
+        |  transition types          (timecnt)                    |
         +---------------------------------------------------------+
         |  local time type records   (typecnt x 6)                |
         +---------------------------------------------------------+
@@ -364,10 +364,10 @@
       number of time values is specified by the 'timecnt' field in the
       header.
 
-   transition time index:  A series of one-octet unsigned integers
+   transition types:  A series of one-octet unsigned integers
       specifying the type of local time of the same-indexed transition
       time.  These values serve as indices into the array of local time
-      type records.  The number of time indices is specified by the
+      type records.  The number of type indices is specified by the
       'timecnt' field in the header.
 
    local time type records:  A series of six-octet records specifying a
@@ -454,6 +454,30 @@
       time.  The number of values is specified by the 'isutccnt' field
       in the header.
 
+   The type corresponding to a transition time specifies local time
+   for timestamps starting at the given transition time and continuing
+   up to and not including the next transition time.  Local time for
+   timestamps on or after the last transition is specified by the TZ
+   string (see "TZif Footer") if present and nonempty, and otherwise
+   is specified by the last transition type.  Local time for
+   timestamps before the first transition time (or for all timestamps
+   if no transitions are present) is specified by the time type
+   computed from the following rules:
+
+     1.  Time type 0 (the first time type) if this time type is not
+     	 used in any transitions.
+
+     2.  If rule (1) does not apply, time type T if the first
+     	 transition is to a daylight saving time type V, T is a
+     	 standard time type that is less than V, and no standard time
+     	 type U is in the range T < U < V.
+
+     3.  If rules (1) and (2) do not apply, the lowest-numbered
+     	 standard time type.
+
+     4.  If rules (1) through (3) do not apply, time type 0.
+   
+
 3.3.  TZif Footer
 
    The TZif footer is structured as follows (the number of octets
@@ -475,7 +499,12 @@
       variable as defined in Section 8 of the "Base Definitions" Volume
       of [POSIX].  If empty, the corresponding information is not
       available.  Note that the string MUST NOT be NUL-terminated and
-      SHOULD NOT begin with the ':' (colon) character.
+      SHOULD NOT begin with the ':' (colon) character.  If the string
+      is nonempty, at least one transition MUST be present in the
+      64-bit data, and the TZ string MUST be consistent with the last
+      64-bit transition - i.e., evaluating the TZ string at the time
+      of the last transition should yield the same time type as the
+      time type specified in the last transition.
 
 3.3.1.  TZ String Extensions

---

From: Ken Murchison <[email-masked]>
Date: Tue, 29 May 2018 11:05:10 -0400

Patch applied.

On 05/29/2018 10:42 AM, Paul Eggert wrote:
> This comment is inspired by the seemingly-weird "MUST NOT" in the 
> "typecnt" definition. It turns out that there's a good reason for the 
> "MUST NOT", that current clients widely rely on the "MUST NOT", and 
> that we should document the reason why, which has to do with 
> timestamps before the first transition (what type of time are they?). 
> While we're at it, there's a lesser problem with timestamps after the 
> last transition. Plus, the draft never clearly specifies that a 
> transition specifies time types for all timestamps up to (but not 
> _______________________________________________
> Tzdist-bis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tzdist-bis

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC