Subject: [Tzdist-bis] Fwd: the default time-type bugaboo raises its ugly head again

From: Arthur David Olson <[email-masked]>
Date: Mon, 4 Jun 2018 22:49:51 -0400

---------- Forwarded message ----------
From: Arthur David Olson <[email-masked]>
Date: Mon, Jun 4, 2018 at 6:46 AM
Subject: Re: the default time-type bugaboo raises its ugly head again
To: Paul Eggert <[email-masked]>

Thanks for the heads up on the proposed changes; I have now subcribed to
the tzdist-bis list (or at least have tried to).

> * Even with the attached patch, the spec requires at least one time type
in both 32- and 64-bit data. However, if there are no transitions and the TZ
> string is nonempty, no time type is used or needed. Should we relax the
TZif spec to allow no time types in this case? If we do, that would allow
> slightly-smaller type-4 TZif files that omit 32-bit data via a dummy with
zero time types. A downside, though, is that the reference code and glibc
>  currently reject such files, on the grounds that tzfile(5) says that
there must be at least one time type.

Given readers in the wild that will reject files with zero time types,
seems best to require at least one. (The requirement for at least one
predates the addition of the POSIX-style string to the end of TZif files.)
May want to tweak the reference implementation to accept files with zero
time types.

> * The spec requires transitions and leap seconds to be listed in
"ascending order". Does this clearly prohibit duplicate entries? If not,
such a
> prohibition should probably be added.

"strictly ascending order" might cover this.

> * Should the spec require that a leap second record's 'corr' value
differs from the preceding record's 'corr' by at most 1? (Or by exactly 1,
if no-op
> records are not allowed?) That is how actual leap seconds work, and I
suspect (though I don't know) that some TZif readers may rely on this.

I'd go with the spec requiring exactly one, the best match to what IERS
does.

> * Should the spec recommend that every time type is used in at least one transition
(except that time type 0 need not be used if there is at least
> one transition)? Although any good TZif generator should do this, this is
merely an optimization (i.e., it omits unnecessary bloat in the TZif file).
> Similarly for the time zone designations array: should the spec recommend
that every character in that array be used by at least one time type record?

Both sound recommendations.

The reference implementation should probably continue to accept files that
don't meet the 'corr' requirement or that have unused or duplicate elements.

I feel a tzlint coming on.-)

    --ado

On Mon, Jun 4, 2018 at 3:43 AM, Paul Eggert <[email-masked]> wrote:

> Are you subscribed to the tzdist-bis mailing list? I'd appreciate it if
> you had the time to look over the default-time-type changes I proposed
> recently, here:
>
> https://www.ietf.org/mail-archive/web/tzdist-bis/current/msg00087.html
>
> The idea is to simplify the rule for reading TZif files so that clients
> can just use time type 0 as the default type. This has been a tricky area
> over the years and your expertise would be appreciated.
>