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

[Ian Abbott]

On 21/03/2022 12:21, Peter Krefting via tz wrote:
> Hi!
> 
> 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"):
> 
>    ~ # TZ=Europe/Oslo date
>    Mon Mar 21 13:08:32 CET 2022
>    ~ # TZ=Europe/London date
>    Mon Mar 21 12:08:36 GMT 2022
>    ~ # TZ=Etc/GMT+1 date
>    Mon Mar 21 12:08:43 -00 2022
>    ~ # TZ=Etc/GMT+2 date
>    Mon Mar 21 12:08:45 -00 2022
> 
> This is particularly severe for our devices since previous versions of our
> software only supported UTC offsets, and these are automatically updated to
> these GMT+xx and GMT-xx timezones on update, so many of our customers are
> expected to have these zones configured.
> 
> We are running with "-r cutoff -b fat", where cutoff depends on the release
> date, and the embedded software currenlty is using GNU libc 2.20.
> 
> Reverting 5f06f9a3182d2c2942be1b678e4defa9c7400653 fixes the issue for us,
> but is probably not the correct approach.
> 

I guess this bug would affect all timezones that have no transitions?

-- 
-=( Ian Abbott <abbotti at mev.co.uk> || MEV Ltd. is a company  )=-
-=( registered in England & Wales.  Regd. number: 02862268.  )=-
-=( Regd. addr.: S11 & 12 Building 67, Europa Business Park, )=-
-=( Bird Hall Lane, STOCKPORT, SK3 0XA, UK. || www.mev.co.uk )=-