[tz] Etc/GMT+nn and Etc/GMT-nn not working since zic 2021d
abbotti at mev.co.uk
Tue Mar 22 16:00:41 UTC 2022
On 21/03/2022 12: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
> 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 )=-
More information about the tz