[tz] Etc/GMT+nn and Etc/GMT-nn not working since zic 2021d

[Paul Eggert]

On 3/21/22 07:21, Peter Krefting via tz wrote:
> I am creating timezone data for an embedded device, and with space as a
> premium I run zic with the -r parameter to cut off all time change
> information from before the software release date, as this is not 
> relevant
> for the system.
>
> Since commit 5f06f9a3182d2c2942be1b678e4defa9c7400653 (included in 
> 2021d),
> this causes the Etc/GMT+xx and Etc/GMT-xx timezones not to work, they 
> always
> report GMT ("-00"): 

Thanks for reporting that. I finally found the time to look into this, 
and the problem is more serious than I thought in my first casual look 
in March. It means one cannot reliably use zic's -r option to specify a 
low boundary. Please try the first attached patch. Something like it 
should appear in the next TZDB release.

The second attached patch is related: it documents that -r might grow 
TZif files instead of shrinking them, something that may interest you 
given that you're working with small devices.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-bug-with-zic-r-cutoff-before-1st-transition.patch
Type: text/x-patch
Size: 10038 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/tz/attachments/20220630/017289d9/0001-Fix-bug-with-zic-r-cutoff-before-1st-transition-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Document-that-zic-r-doesn-t-necessarily-shrink.patch
Type: text/x-patch
Size: 1512 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/tz/attachments/20220630/017289d9/0002-Document-that-zic-r-doesn-t-necessarily-shrink-0001.patch>