Etc/GMT+nn and Etc/GMT-nn not working since zic 2021d
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. -- \\// Peter - http://www.softwolves.pp.se/
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 )=-
On 3/22/22 09:00, Ian Abbott via tz wrote:
I guess this bug would affect all timezones that have no transitions?
More generally, the bug occurs if you use 'zic -r @T' with a timezone that lacks transitions before T. This means the truncated TZif file will be larger than an untruncated TZif file would be, because the truncated file needs to record the truncation timestamp in addition to all the other stuff. I'll look into patching the bug.
On 22/03/2022 16:23, Paul Eggert wrote:
On 3/22/22 09:00, Ian Abbott via tz wrote:
I guess this bug would affect all timezones that have no transitions?
More generally, the bug occurs if you use 'zic -r @T' with a timezone that lacks transitions before T. This means the truncated TZif file will be larger than an untruncated TZif file would be, because the truncated file needs to record the truncation timestamp in addition to all the other stuff. I'll look into patching the bug.
Perhaps the low/high cutoff points could be rounded down/up to actual transition points (if they exist) or beginning/end of representable time? That might put more leap second transitions in the zone though. -- -=( 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 )=-
On 3/22/22 09:39, Ian Abbott wrote:
Perhaps the low/high cutoff points could be rounded down/up to actual transition points (if they exist) or beginning/end of representable time? That might put more leap second transitions in the zone though.
Yes, and the idea of zic -r is to represent the cutoff points as specified, using the RFC 8536 format, so adjusting them is probably not a good idea.
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.
Paul Eggert:
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.
This patch does indeed fix the problem for me. Thank you! -- \\// Peter - http://www.softwolves.pp.se/
účastníci (3)
-
Ian Abbott -
Paul Eggert -
Peter Krefting