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@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 )=-