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