[tz] Extra transition type is generated by zic with -r specified

Almaz Mingaleev mingaleev at google.com
Mon Oct 25 18:15:42 UTC 2021


How feasible is it to add a flag which does not truncate the file?
Also, RFC [1] says the following about TZ string:
"the string MUST be
consistent with the last version 2+ transition". Doesn't
truncation violate that?

[1] https://datatracker.ietf.org/doc/html/rfc8536#section-3.3

On Mon, 25 Oct 2021, 19:06 Paul Eggert, <eggert at cs.ucla.edu> wrote:

> On 10/25/21 04:18, Almaz Mingaleev via tz wrote:
>
> > Is that a bug or is there a reason for such behaviour?
>
> The behavior you're describing comes from the following change that was
> circulated on the mailing list on October 15 and released in 2021e:
>
> https://mm.icann.org/pipermail/tz/2021-October/030980.html
>
> The idea is to let TZif readers know that the TZif file is truncated.
> Before this change, there was no way that a TZif reader would know that
> it's dealing with a truncated TZif file.
>
> The next draft of Internet RFC 8536bis is planned to recommend this sort
> of thing, unless some problems turn up with it (and if so, please let us
> know).
>
> We could modify zic to use some UT offset other than 0 for the affected
> timestamps; this would also follow the next draft's recommendation.
> Although I considered doing that, I worried that it'd be confusing for
> the TZif file to say that after the year 2100 Lord Howe Island will be
> at UT +11 with an abbreviation of "-00".
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/tz/attachments/20211025/3576c897/attachment.html>


More information about the tz mailing list