Subject: [Tzdist-bis] Comments on draft-murchinson-tzdist-tzif-00

From: Eliot Lear <[email-masked]>
Date: Sun, 20 May 2018 15:06:50 +0200

Hi everyone,

This is my first round review of this draft.  I compared it against my
code, and the header matches, but I haven't yet tested the data
components.  The field lengths seem to match, though.  I'll say more
when I've finished my little test code (I'm only doing 32 bit).

Big Questions

How do you tell if you are receiving a 32-bit wide or 64-bit wide file? 
One easy way to do this would be to vary the magic field.  Another would
be to nip off another byte from reserved to indicate this.

Is there a good example of a file that currently has leap second
indicators?  There's not much on my Mac so far as I can tell... (leapcnt
= 0 always).

Nits:

Updated normative boilerplate is needed.  Here it is:

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119][RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Are you sure you wouldn't want to do the diagrams in the more classic
way, like this:

>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It makes clear exactly where the bit boundaries are, as opposed to using
x4, x6 and x8.  If you're not going to do that, I would indicate below
the captions what the xN means.

Suggested editorial:

OLD:

>    NOTE: All multi-octet integer values MUST be stored in big-endian
>    format (high-order octet first).

NEW:
>    NOTE: All multi-octet integer values MUST be stored in network byte
> order
>    format (high-order octet first, otherwise known as big-endian).

Eliot

---

From: Paul Eggert <[email-masked]>
Date: Sun, 20 May 2018 18:04:36 -0700

> How do you tell if you are receiving a 32-bit wide or 64-bit wide file?

The version field tells you. If it's version 2 format or later, you are 
receiving both 32-bit and 64-bit data in one file. Earlier formats are 32-bit 
only. This is specified in section 3 under 'version'; perhaps it should be 
mentioned earlier?

> indicators?  There's not much on my Mac so far as I can tell... (leapcnt

On many GNU/Linux distributions (e.g., RHEL, Ubuntu), you can find examples 
under /usr/share/zoneinfo/right, e.g., /usr/share/zoneinfo/right/Pacific/Fiji.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 21 May 2018 11:20:53 +0200

On 21.05.18 03:04, Paul Eggert wrote:
> The version field tells you. If it's version 2 format or later, you
> are receiving both 32-bit and 64-bit data in one file. Earlier formats
> are 32-bit only. This is specified in section 3 under 'version';
> perhaps it should be mentioned earlier?

Ahhhh.  Well... I missed it, but sure enough I wrote out the 64-bit code
and it's there.  Yeah, I would bring it out earlier.  One way to do that
would be with a simple diagram like this:

         v1                      v2/v3
  +-----------------+ 	 +-----------------+
  |    header for   |    |   header for    |
  | 32-bit entries  |    |  32-bit entries |
  +-----------------+    +-----------------+
  |                 |    |                 |
  |  32-bit data    |    |   32-bit data   |
  |                 |    |                 |
  +-----------------+    +-----------------+
      	      	      	 |   header for    |
                         |  64-bit entries |
                         +-----------------+
                         |                 |
                         |  64-bit entries |
                         |                 |
                         +-----------------+
                         |NL| POSIX Str |NL|
                         +-----------------+

You might also add as a footnote, then, that if one only wants part of
the information, one can seek around based on the two header fields. 
You've neatly laid out the formula to do that (and my test code did this).

I would ALSO add some text that while it would be nice to believe that
32- and 64-bit data are consistent, there is no guarantee that this is
so.  Pick one and hope for the best.  You might ALSO add a SHOULD in
there about those writing the files to indicate that they should strive
to make the
information consistent. 

Also, we have our own little Y2K issue coming up again.  Experience
shows that it takes a LONG time to make changes.  What advice should be
given as 19 Jan 2038 approaches?  I would like to suggest that you add
something along the lines of the following:

> Implementations SHOULD use the 64-bit part of the file.  Future
> versions of this file may not include the 32-bit information.  

You could arguably define such a format now, if you wanted.

I'm going to move on from here to look at the ToDos at the top of the
draft over the next few days, but thus far I'm not finding any errors.

Eliot

---

From: Paul Eggert <[email-masked]>
Date: Mon, 21 May 2018 09:38:37 -0700

On 05/21/2018 02:20 AM, Eliot Lear wrote:
> Implementations SHOULD use the 64-bit part of the file.  Future  > versions of this file may not include the 32-bit information.
Yes, something along those lines should be added. How about if we word 
it even more strongly, by appending something like this?

Version 1 files SHOULD not be generated, as they do not support 
transition times after the year 2038.

---

From: Ken Murchison <[email-masked]>
Date: Tue, 22 May 2018 12:25:13 -0400

>     14 [RFC2119][RFC8174] when, and only when, they appear in all

Done.

> Are you sure you wouldn't want to do the diagrams in the more classic

Are you thinking of doing this at a bit level or byte level? Creating 
the diagram at a bit level, doesn't allow us to fit 4 bytes in a single 
row when rendered in the text format.

>>     format (high-order octet first, otherwise known as big-endian).

Done.

-- 

Ken Murchison
Cyrus Development Team
FastMail US LLC