Subject: [Tzdist-bis] TZDIST and TZif version 2/3

From: Ken Murchison <[email-masked]>
Date: Mon, 18 Jun 2018 14:26:52 -0400

Looking into adding text recommending/mandating that a TZDIST server 
return version 2 or 3 TZif files.

Question: Is it illegal/undesirable to generate a version 3 file of the 
TZ string doesn't use extensions?  Is there any reason to not just 
mandate version 3 for TZDIST?

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Paul Eggert <[email-masked]>
Date: Mon, 18 Jun 2018 11:41:51 -0700

Ken Murchison wrote:
> Question: Is it illegal/undesirable to generate a version 3 file of the TZ 
> string doesn't use extensions?  Is there any reason to not just mandate version 
> 3 for TZDIST?

Well, zic outputs version 2 if the data can be exactly represented in version 2, 
and outputs version 3 otherwise. The idea is to cater to picky clients that 
insist on version 2 for some (probably mistaken) reason. We don't know whether 
there are any such clients; quite possibly there aren't any, as the tradition is 
to be generous in what you read.

As a result, almost all TZif files in the wild are labeled as version 2 right 
now, since only a small set of these files actually need version 3 features. 
Software based on zic will likely want to do something similar.

---

From: Ken Murchison <[email-masked]>
Date: Mon, 18 Jun 2018 14:46:04 -0400

On 06/18/2018 02:41 PM, Paul Eggert wrote:
> Ken Murchison wrote:
>> Question: Is it illegal/undesirable to generate a version 3 file of 
>> the TZ string doesn't use extensions?  Is there any reason to not 
>> just mandate version 3 for TZDIST?
>
> Well, zic outputs version 2 if the data can be exactly represented in 
> version 2, and outputs version 3 otherwise. The idea is to cater to 
> picky clients that insist on version 2 for some (probably mistaken) 
> reason. We don't know whether there are any such clients; quite 
> possibly there aren't any, as the tradition is to be generous in what 
> you read.
>
> As a result, almost all TZif files in the wild are labeled as version 
> 2 right now, since only a small set of these files actually need 
> version 3 features. Software based on zic will likely want to do 
> something similar.

OK, so how do we want to phrase this?  Do we want to prohibit version 1 
in TZDIST?

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Paul Eggert <[email-masked]>
Date: Mon, 18 Jun 2018 15:18:22 -0700

On 06/18/2018 11:46 AM, Ken Murchison wrote:
> OK, so how do we want to phrase this?  Do we want to prohibit version 
> 1 in TZDIST? 

Currently the spec says that implementations SHOULD NOT generate version 
1. We could change that to a "MUST NOT", though I'm not sure I see the 
point.

As far as the 2-vs-3 issue, how about the attached patch? It also fixes 
a small problem in the neighborhood that I noticed: the 32-bit data 
should be consistent with the TZ string in the footer.

--- draft-murchison-tzdist-tzif-06.xml	2018-06-17 03:09:24.540438847 -0700
+++ draft-murchison-tzdist-tzif-06-3.xml	2018-06-18 15:17:58.506395942 -0700
@@ -255,9 +255,11 @@
	      year 2038.</t>
	
	      <t>Implementations SHOULD generate version 2 or 3 files.
+	      Implementations SHOULD generate a version 3 file if it models
+	      the corresponding timestamps more accurately than version 2 would.
	      The sequence of time changes defined by the 32-bit header and
	      data block SHOULD be a contiguous subsequence of the time
-	      changes defined by the 64-bit header and data block.
+	      changes defined by the 64-bit header and data block and the footer.
	      When reading a version 2 or 3 file, implementations SHOULD
	      ignore the 32-bit header and data block except for the purpose
	      of skipping over them.</t>