Subject: [Tzdist-bis] TZif verision 4 (revisit)

From: Ken Murchison <[email-masked]>
Date: Thu, 28 Jun 2018 13:58:54 -0400

Could we simply define a version 4 file as having all counts in the 
32-bit header as being zero?

Obviously, code that can only read version 1 files would be screwed, but 
any other software would quickly skip the 32-bit header and use the 
64-bit data, correct?

I'm sure this is too simple of a solution but I figured I'd throw it out 
there.

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Paul Eggert <[email-masked]>
Date: Thu, 28 Jun 2018 23:14:08 -0700

Ken Murchison wrote:
> Could we simply define a version 4 file as having all counts in the 32-bit 
> header as being zero?
> 
> Obviously, code that can only read version 1 files would be screwed, but any 
> other software would quickly skip the 32-bit header and use the 64-bit data, 
> correct?

Unfortunately no, because a goodly amount of existing client code checks that 
typecnt is nonzero and rejects a TZif file if it's zero. This is because the 
reference tzfile.5 man page has said that typecnt must be nonzero, and this 
requirement has been in that man page since early 1986 (before the first release 
of tzcode!).

Last month I changed the reference implementation to remove this restriction, here:

https://github.com/eggert/tz/commit/cac4238a8e5c621f4a38dd83b0432e0634eb72bd

However, this hasn't been part of any tzdb release yet, and lots of client code 
will reject a file with zero typecnt.

If we want to define type 4 at all (which is probably best deferred for a later 
RFC), I suggest defining it to have all 32-bit counts 0 except that typecnt 
should be 1 (and may be 0 only if you don't care about existing clients).