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@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".