zoneinfo generating issues
Hi: Recently, I wanted to write a program to watch the change of timezone database. I got newest version from this address: https://data.iana.org/time-zones/releases/tzdata2021a.tar.gz. I used zic (version: zic (tzcode) 2020c, system: CentOS Linux release 7.6.1810 (Core)) to generate the zoneinfo. I pick up some zones with local timeto calculate utc time to verify the changes using both the new and currently used version tzdata, here is diff: zone local time by 2021a utc time by 2020d utc time America/Adak 2022-11-01 00:00:00 2022-11-01 09:00:00 2022-11-01 10:00:00 America/Anchorage 2022-11-01 00:00:00 2022-11-01 08:00:00 2022-11-01 09:00:00 America/Asuncion 2022-10-01 00:00:00 2022-10-01 04:00:00 2022-10-01 03:00:00 America/Atka 2022-11-01 00:00:00 2022-11-01 09:00:00 2022-11-01 10:00:00 Those zones are not changed from version 2020d to 2021a. I am very confused and not sure if I generated the zoneinfo in the right way. Here was what do: # mkdir zoneinfo # cd tzdata2021a # zic -d ../zoneinfo -L ./leapseconds africa antarctica asia australasia europe northamerica southamerica etcetera backward factory I was wondering if you could provide me some help. I really appreciate your reply. Sincerely, wangmm
On 2021-03-03 04:20, 汪蒙蒙(木之) via tz wrote:
Recently, I wanted to write a program to watch the change of timezone database. I got newest version from this address: <https://data.iana.org/time-zones/releases/tzdata2021a.tar.gz>. I used zic (version: zic (tzcode) 2020c, system: CentOS Linux release 7.6.1810 (Core)) to generate the zoneinfo. I pick up some zones with local time to calculate utc time to verify the changes using both the new and currently used version tzdata, here is diff: > zone local time by 2021a utc time by 2020d utc time America/Adak 2022-11-01 00:00:00 2022-11-01 09:00:00 2022-11-01 10:00:00 America/Anchorage 2022-11-01 00:00:00 2022-11-01 08:00:00 2022-11-01 09:00:00 America/Asuncion 2022-10-01 00:00:00 2022-10-01 04:00:00 2022-10-01 03:00:00 America/Atka 2022-11-01 00:00:00 2022-11-01 09:00:00 2022-11-01 10:00:00
Those zones are not changed from version 2020d to 2021a. I am very confused and not sure if I generated the zoneinfo in the right way. Here was what do:
# mkdir zoneinfo # cd tzdata2021a # zic -d ../zoneinfo -L ./leapseconds africa antarctica asia australasia europe northamerica southamerica etcetera backward factory
I was wondering if you could provide me some help. I really appreciate your reply.
We have no clue whether what you are using accesses the data files you generated, and what code it is using to display what times. Please show logs of how you generated the tzdata files, then accessed them to generate the times, and any custom scripts or source code you used. The best way to display times is using the tzcode zdump utility on the zoneinfo data files for the zones you are using. In general, it is best to assume the problem is in what you are doing or how you are doing it, and generate copious detailed debug output so you can see what your code is actually doing, as opposed to what you may think it does. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]
On 3/3/21 3:20 AM, 汪蒙蒙(木之) via tz wrote:
Those zones are not changed from version 2020d to 2021a. I am very confused and not sure if I generated the zoneinfo in the right way.
As Brian wrote, we'd need more info before being able to help much. That being said, you can check things by comparing your 2020d America/Adak file to your 2021a America/Adak file. They ought to be identical. If they're not, it's a problem with how you generated the files. If they are, it's a problem with the program you wrote.
Thank you, I have made a docker image which can be pulled from: "docker.io/damon0708/zic:v0.1". The DockerFile is simple: FROM alpine WORKDIR /app/ RUN apk add tzdata The image has been installed a tzdata with zic and zoneinfo in /usr/share/zoneinfo, which version is 2021a.You can pull it to local and run a container from it by "docker run -ti damon0708/zic:v0.1 /bin/sh". After running a container, # zic --version zic (tzcode) 2021a # mkdir tzdata2021a && cd tzdata2021a # wget https://data.iana.org/time-zones/releases/tzdata2021a.tar.gz # tar zxf tzdata2021a.tar.gz<https://data.iana.org/time-zones/releases/tzdata2021a.tar.gz> # mkdir ../zoneinfo # zic -d ../zoneinfo/ -L leapseconds africa antarctica asia australasia europe northamerica southamerica etcetera backward factory # cp -f iso3166.tab zone1970.tab zone.tab ../zoneinfo/ # diff ../zoneinfo/America/Adak /usr/share/zoneinfo/America/Adak Files America/Adak and /usr/share/zoneinfo/America/Adak differ I ran the same check, still got the result: zone local time by 2021a utc time by 2020d utc time America/Adak 2022-11-01 00:00:00 2022-11-01 09:00:00 2022-11-01 10:00:00 America/Anchorage 2022-11-01 00:00:00 2022-11-01 08:00:00 2022-11-01 09:00:00 America/Asuncion 2022-10-01 00:00:00 2022-10-01 04:00:00 2022-10-01 03:00:00 America/Atka 2022-11-01 00:00:00 2022-11-01 09:00:00 2022-11-01 10:00:00 By the way, I also used the zic(version: @(#)zic.c 8.22) in mac os to generate zoneinfo data, but the check showed no diff in America/Adak America/Anchorage America/Asuncion America/Atka. ________________________________ 发件人: Paul Eggert <eggert@cs.ucla.edu> 发送时间: 2021年3月4日 1:41 收件人: 汪蒙蒙(木之) <wangmm@tuya.com> 抄送: Time zone mailing list <tz@iana.org> 主题: Re: [tz] zoneinfo generating issues On 3/3/21 3:20 AM, 汪蒙蒙(木之) via tz wrote:
Those zones are not changed from version 2020d to 2021a. I am very confused and not sure if I generated the zoneinfo in the right way.
As Brian wrote, we'd need more info before being able to help much. That being said, you can check things by comparing your 2020d America/Adak file to your 2021a America/Adak file. They ought to be identical. If they're not, it's a problem with how you generated the files. If they are, it's a problem with the program you wrote.
On 3/3/21 11:03 PM, 汪蒙蒙(木之) wrote:
the check showed no diff in America/Adak America/Anchorage America/Asuncion America/Atka
In that case I don't see how the tzdb distribution (either code or data) can be the problem here. If I understand things correctly, you say it's producing TZif files like America/Adak that are identical to those of previous releases, but that your analysis tool is behaves differently on those two identical TZif files. I expect you'll have to look into the problem on your end.
Sorry, I made a mistake and the actual diff result is, zone local time by 2020d utc time by 2021a utc time America/Adak 2022-11-01 00:00:00 2022-11-01 09:00:00 2022-11-01 10:00:00 America/Anchorage 2022-11-01 00:00:00 2022-11-01 08:00:00 2022-11-01 09:00:00 America/Asuncion 2022-10-01 00:00:00 2022-10-01 04:00:00 2022-10-01 03:00:00 America/Atka 2022-11-01 00:00:00 2022-11-01 09:00:00 2022-11-01 10:00:00 but the problem still exists. I have put my analysis tool and its code in the docker image, "damon0708/zic:v0.3". The tool is writen in golang and easy to be used. # ./main -h -l string local time need to transfer (default "2022-11-01 00:00:00") -path string used to parse timezone (default "/usr/share/zoneinfo") -tz string the timezone you want transfer (default "America/Adak") After making the zoneinfo in path "/app/zoneinfo", # ./main -l "2022-11-01 00:00:00" -path "/usr/share/zoneinfo" -tz "America/Adak" UTC: 2022-11-01 09:00:00 +0000 UTC # ./main -l "2022-11-01 00:00:00" -path "/app/zoneinfo" -tz "America/Adak" UTC: 2022-11-01 10:00:00 +0000 UTC The tool uses the golang standard library "time", which can be specified the zoneinfo path by the env "ZONEINFO". So I don't think it is the problem of the tool. 发件人: Paul Eggert <eggert@cs.ucla.edu> 发送时间: 2021年3月4日 17:13 收件人: 汪蒙蒙(木之) <wangmm@tuya.com> 抄送: Time zone mailing list <tz@iana.org> 主题: Re: 回复: [tz] zoneinfo generating issues On 3/3/21 11:03 PM, 汪蒙蒙(木之) wrote:
the check showed no diff in America/Adak America/Anchorage America/Asuncion America/Atka
In that case I don't see how the tzdb distribution (either code or data) can be the problem here. If I understand things correctly, you say it's producing TZif files like America/Adak that are identical to those of previous releases, but that your analysis tool is behaves differently on those two identical TZif files. I expect you'll have to look into the problem on your end.
On 3/5/21 2:01 AM, 汪蒙蒙(木之) wrote:
# ./main -l "2022-11-01 00:00:00" -path "/usr/share/zoneinfo" -tz "America/Adak" UTC: 2022-11-01 09:00:00 +0000 UTC # ./main -l "2022-11-01 00:00:00" -path "/app/zoneinfo" -tz "America/Adak" UTC: 2022-11-01 10:00:00 +0000 UTC
What is the output of these shell commands? cmp /usr/share/zoneinfo/America/Adak /app/zoneinfo/America/Adak You seem to be indicating that these files are identical but I suspect they're not. If they're not identical, please send the output of these shell commands: od -t x1 /usr/share/zoneinfo/America/Adak od -t x1 /app/zoneinfo/America/Adak I'm reluctant to look at Docker images as they are complicated beasts. It would be better if you could isolate your problem to a short Go program that illustrates the issue.
On 05/03/2021 10:01, 汪蒙蒙(木之) via tz wrote:
Sorry, I made a mistake and the actual diff result is, zone local time by 2020d utc time by 2021a utc time America/Adak 2022-11-01 00:00:00 2022-11-01 09:00:00 2022-11-01 10:00:00 America/Anchorage 2022-11-01 00:00:00 2022-11-01 08:00:00 2022-11-01 09:00:00 America/Asuncion 2022-10-01 00:00:00 2022-10-01 04:00:00 2022-10-01 03:00:00 America/Atka 2022-11-01 00:00:00 2022-11-01 09:00:00 2022-11-01 10:00:00
but the problem still exists. I have put my analysis tool and its codein the docker image, "damon0708/zic:v0.3". The tool is writen in golang and easy to be used. # ./main -h -l string local time need to transfer (default "2022-11-01 00:00:00") -path string used to parse timezone (default "/usr/share/zoneinfo") -tz string the timezone you want transfer (default "America/Adak")
After making the zoneinfo in path "/app/zoneinfo",
# ./main -l "2022-11-01 00:00:00" -path "/usr/share/zoneinfo" -tz "America/Adak" UTC: 2022-11-01 09:00:00 +0000 UTC # ./main -l "2022-11-01 00:00:00" -path "/app/zoneinfo" -tz "America/Adak" UTC: 2022-11-01 10:00:00 +0000 UTC
The tool uses the golang standard library "time", which can be specified the zoneinfo path by the env "ZONEINFO". So I don't think it is the problem of the tool.
The problem seems to be related to the use of leapseconds. # ./main -l "2022-11-01 00:00:00" -path /usr/share/zoneinfo -tz America/Adak UTC: 2022-11-01 09:00:00 +0000 UTC # ./main -l "2022-11-01 00:00:00" -path /usr/share/zoneinfo/right -tz America/Adak UTC: 2022-11-01 10:00:00 +0000 UTC I've attached the source of main.go that Paul wanted. -- -=( 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 05/03/2021 20:29, Ian Abbott via tz wrote:
On 05/03/2021 10:01, 汪蒙蒙(木之) via tz wrote:
but the problem still exists. I have put my analysis tool and its codein the docker image, "damon0708/zic:v0.3". The tool is writen in golang and easy to be used. # ./main -h -l string local time need to transfer (default "2022-11-01 00:00:00") -path string used to parse timezone (default "/usr/share/zoneinfo") -tz string the timezone you want transfer (default "America/Adak")
After making the zoneinfo in path "/app/zoneinfo",
# ./main -l "2022-11-01 00:00:00" -path "/usr/share/zoneinfo" -tz "America/Adak" UTC: 2022-11-01 09:00:00 +0000 UTC # ./main -l "2022-11-01 00:00:00" -path "/app/zoneinfo" -tz "America/Adak" UTC: 2022-11-01 10:00:00 +0000 UTC
The tool uses the golang standard library "time", which can be specified the zoneinfo path by the env "ZONEINFO". So I don't think it is the problem of the tool.
The problem seems to be related to the use of leapseconds.
# ./main -l "2022-11-01 00:00:00" -path /usr/share/zoneinfo -tz America/Adak UTC: 2022-11-01 09:00:00 +0000 UTC # ./main -l "2022-11-01 00:00:00" -path /usr/share/zoneinfo/right -tz America/Adak UTC: 2022-11-01 10:00:00 +0000 UTC
I ran that test in the docker image, but I cannot reproduce it on my Debian testing systems. Both commands produce a UTC time of 10:00:00 on my Debian systems. It could be a different golang environment, or it could be due to the Alpine Linux docker image using musl libc rather than glibc. -- -=( Ian Abbott <abbotti@mev.co.uk> || Web: www.mev.co.uk )=- -=( MEV Ltd. is a company registered in England & Wales. )=- -=( Registered number: 02862268. Registered address: )=- -=( 15 West Park Road, Bramhall, STOCKPORT, SK7 3JZ, UK. )=-
On 05/03/2021 23:02, Ian Abbott wrote:
On 05/03/2021 20:29, Ian Abbott via tz wrote:
The problem seems to be related to the use of leapseconds.
# ./main -l "2022-11-01 00:00:00" -path /usr/share/zoneinfo -tz America/Adak UTC: 2022-11-01 09:00:00 +0000 UTC # ./main -l "2022-11-01 00:00:00" -path /usr/share/zoneinfo/right -tz America/Adak UTC: 2022-11-01 10:00:00 +0000 UTC
I ran that test in the docker image, but I cannot reproduce it on my Debian testing systems. Both commands produce a UTC time of 10:00:00 on my Debian systems.
Correction: Both commands produced a UTC time of 09:00:00 (not 10:00:00) on my Debian system. Sorry for mis-reporting! -- -=( Ian Abbott <abbotti@mev.co.uk> || Web: www.mev.co.uk )=- -=( MEV Ltd. is a company registered in England & Wales. )=- -=( Registered number: 02862268. Registered address: )=- -=( 15 West Park Road, Bramhall, STOCKPORT, SK7 3JZ, UK. )=-
On 2021-03-05 20:29, Ian Abbott via tz wrote:
The problem seems to be related to the use of leapseconds.
# ./main -l "2022-11-01 00:00:00" -path /usr/share/zoneinfo -tz America/Adak UTC: 2022-11-01 09:00:00 +0000 UTC # ./main -l "2022-11-01 00:00:00" -path /usr/share/zoneinfo/right -tz America/Adak UTC: 2022-11-01 10:00:00 +0000 UTC
Shouldn't you compare # ./main -l "2022-11-01 00:00:00" -path /usr/share/zoneinfo -tz America/Adak with # ./main -l "2022-11-01 00:00:27" -path /usr/share/zoneinfo/right -tz America/Adak? Michael Deckers.
Shouldn't you compare # ./main -l "2022-11-01 00:00:00" -path /usr/share/zoneinfo -tz America/Adak with # ./main -l "2022-11-01 00:00:27" -path /usr/share/zoneinfo/right -tz America/Adak?
Thanks a lot, I mis-used the "zic -L", which generated the zoneinfo of leapseconds. ________________________________ 发件人: Michael H Deckers <michael.h.deckers@googlemail.com> 发送时间: 2021年3月6日 8:23 收件人: Ian Abbott <abbotti@mev.co.uk>; 汪蒙蒙(木之) <wangmm@tuya.com>; Paul Eggert <eggert@cs.ucla.edu> 抄送: Time zone mailing list <tz@iana.org> 主题: Re: [tz] 回复: 回复: zoneinfo generating issues On 2021-03-05 20:29, Ian Abbott via tz wrote:
The problem seems to be related to the use of leapseconds.
# ./main -l "2022-11-01 00:00:00" -path /usr/share/zoneinfo -tz America/Adak UTC: 2022-11-01 09:00:00 +0000 UTC # ./main -l "2022-11-01 00:00:00" -path /usr/share/zoneinfo/right -tz America/Adak UTC: 2022-11-01 10:00:00 +0000 UTC
Shouldn't you compare # ./main -l "2022-11-01 00:00:00" -path /usr/share/zoneinfo -tz America/Adak with # ./main -l "2022-11-01 00:00:27" -path /usr/share/zoneinfo/right -tz America/Adak? Michael Deckers.
On 06/03/2021 00:23, Michael H Deckers wrote:
On 2021-03-05 20:29, Ian Abbott via tz wrote:
The problem seems to be related to the use of leapseconds.
# ./main -l "2022-11-01 00:00:00" -path /usr/share/zoneinfo -tz America/Adak UTC: 2022-11-01 09:00:00 +0000 UTC # ./main -l "2022-11-01 00:00:00" -path /usr/share/zoneinfo/right -tz America/Adak UTC: 2022-11-01 10:00:00 +0000 UTC
Shouldn't you compare # ./main -l "2022-11-01 00:00:00" -path /usr/share/zoneinfo -tz America/Adak with # ./main -l "2022-11-01 00:00:27" -path /usr/share/zoneinfo/right -tz America/Adak?
Probably. On the problematic container, that shows a UTC time of 10:00:27, but on my Debian testing machines it shows a UTC time of 09:00:27. There is something very dodgy about the installation of the "/right/" zone files in this container (based on x86_64 Alpine Linux 3.13, with its tzdata2021a-r0 package). None of the DST transitions after 2021 seem to be working: # zdump -c 2021,2023 -i /usr/share/zoneinfo/right/Pacific/Fiji TZ="/usr/share/zoneinfo/right/Pacific/Fiji" - - +125933 "+13" 1 2021-01-17 02 +115933 "+12" 2021-11-14 03 +125933 "+13" 1 Compare with the normal zone files: # zdump -c 2021,2023 -i /usr/share/zoneinfo/Pacific/Fiji TZ="/usr/share/zoneinfo/Pacific/Fiji" - - +13 1 2021-01-17 02 +12 2021-11-14 03 +13 1 2022-01-16 02 +12 2022-11-13 03 +13 1 I've attached the "right" and "normal" versions of the Fiji zoneinfo files as "right.Pacific.Fiji" and "Pacific.Fiji" respectively. Some metadata differences between the files: $ file Pacific.Fiji right.Pacific.Fiji Pacific.Fiji: timezone data, version 3, no gmt time flags, no std time flags, no leap seconds, 64 transition times, 3 abbreviation chars right.Pacific.Fiji: timezone data, version 2, no gmt time flags, no std time flags, 27 leap seconds, 31 transition times, 3 abbreviation chars Also, right.Pacific.Fiji has no TZ string on the end. -- -=( 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 06/03/2021 15:15, Ian Abbott via tz wrote:
There is something very dodgy about the installation of the "/right/" zone files in this container (based on x86_64 Alpine Linux 3.13, with its tzdata2021a-r0 package). None of the DST transitions after 2021 seem to be working:
# zdump -c 2021,2023 -i /usr/share/zoneinfo/right/Pacific/Fiji
TZ="/usr/share/zoneinfo/right/Pacific/Fiji" - - +125933 "+13" 1 2021-01-17 02 +115933 "+12" 2021-11-14 03 +125933 "+13" 1
I've just realized that it is normal (as per the zic man page, I think) for the "right" (a.k.a. "leap") zone files to be truncated at the expiry time of the leapseconds file (although the files installed by Debian zic seem to continue beyond the expiry time). I must admit I wasn't expecting that. I thought the output would continue as though there would be no changes to the leap seconds in the future. -- -=( 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 Mar 6, 2021, at 8:44 AM, Ian Abbott via tz <tz@iana.org> wrote:
I've just realized that it is normal (as per the zic man page, I think) for the "right" (a.k.a. "leap") zone files to be truncated at the expiry time of the leapseconds file (although the files installed by Debian zic seem to continue beyond the expiry time). I must admit I wasn't expecting that. I thought the output would continue as though there would be no changes to the leap seconds in the future.
After all, we don't truncate the files at the date/time when they're generated, given that we have no guarantee that there will be no changes in the future to the offset from UTC, or the DST rules, for a given tzdb region....
On Sat 2021-03-06T15:54:42-0800 Guy Harris via tz hath writ:
After all, we don't truncate the files at the date/time when they're generated, given that we have no guarantee that there will be no changes in the future to the offset from UTC, or the DST rules, for a given tzdb region....
The way the crust is rotating now it is likely that jurisdiction(s) will change time zone rule(s) before there is another leap second. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m
On Sat, 2021-03-06 at 17:27 -0800, Steve Allen via tz wrote:
On Sat 2021-03-06T15:54:42-0800 Guy Harris via tz hath writ:
After all, we don't truncate the files at the date/time when they're generated, given that we have no guarantee that there will be no changes in the future to the offset from UTC, or the DST rules, for a given tzdb region....
The way the crust is rotating now it is likely that jurisdiction(s) will change time zone rule(s) before there is another leap second.
The way the crust is rotating now there will be a negative leap second on June 30, 2031. John Sauter (John_Sauter@systemeyescomputerstore.com) -- get my PGP public key with gpg --locate-external-keys John_Sauter@systemeyescomputerstore.com
On 2021-03-07 08:18, John Sauter via tz wrote:
On Sat, 2021-03-06 at 17:27 -0800, Steve Allen via tz wrote:
On Sat 2021-03-06T15:54:42-0800 Guy Harris via tz hath writ:
After all, we don't truncate the files at the date/time when they're generated, given that we have no guarantee that there will be no changes in the future to the offset from UTC, or the DST rules, for a given tzdb region....
The way the crust is rotating now it is likely that jurisdiction(s) will change time zone rule(s) before there is another leap second.
Or drop leap seconds and declare UTC is GMST.
The way the crust is rotating now there will be a negative leap second on June 30, 2031.
There's a reason nobody is willing to commit to a prediction more than six months in advance. Even then they are not always as expected six months later - the last leap second could have been skipped, as dUT1 did not reach the value expected which would require a change. So it will be a longer than expected interval until the next. However there is evidence of mutual interactions between earth rotation and seismic activity - braking increases earthquakes which foreshadows eruptions. https://www.volcanodiscovery.com/volcano-activity/news/123478/Volcanic-activ... https://www.livescience.com/iceland-earthquakes-volcanic-eruption-2021.html Significant earthquakes may make the distribution of the earth's mass more compact, decrease its moment of inertia and LoD, and increase rotation speed as angular momentum is conserved; significant eruptions which move large masses from the interior to the exterior may have the opposite effect. There may also be effects due to resonance of tidal and natural ocean frequencies. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]
"John" == John Sauter via tz <tz@iana.org> writes:
John> The way the crust is rotating now there will be a negative leap John> second on June 30, 2031. The lack of any leap second (positive or negative) on Jun 30 2031 has already been formally announced: https://datacenter.iers.org/data/latestVersion/16_BULLETIN_C16.txt "NO leap second will be introduced at the end of June 2021. The difference between Coordinated Universal Time UTC and the International Atomic Time TAI is : from 2017 January 1, 0h UTC, until further notice : UTC-TAI = -37 s" IMO, a negative leap second would not be introduced until it became absolutely necessary (assuming we don't abolish leap seconds first), considering the likely disruption that it would cause. That being the case, there is about 800ms of slack available, and the predictions I've seen are for 2021 to run short by only on the order of 20ms, so it would take around 40 years before a negative leap second was required if the current rotation is maintained, or about 8 years if the speedup increases approximately linearly. -- Andrew.
On Sun, 7 Mar 2021 at 13:23, Andrew Gierth via tz <tz@iana.org> wrote:
John> The way the crust is rotating now there will be a negative leap John> second on June 30, 2031.
The lack of any leap second (positive or negative) on Jun 30 2031 has already been formally announced:
https://datacenter.iers.org/data/latestVersion/16_BULLETIN_C16.txt
That (formal) announcement is for June 2021. John's (informal) prediction is for June 2031. -- Tim Parenti
On Sat, 6 Mar 2021 at 11:45, Ian Abbott via tz <tz@iana.org> wrote:
I've just realized that it is normal (as per the zic man page, I think) for the "right" (a.k.a. "leap") zone files to be truncated at the expiry time of the leapseconds file (although the files installed by Debian zic seem to continue beyond the expiry time).
From zic.8: "zic outputs this expiration timestamp by truncating the end of the output file to the timestamp."
Truncation would certainly explain the behavior that is being seen here: In 2020d, the expiry of the leapseconds file was 2021-06-28, so the far future timestamps tested would be interpreted as though they retain the local offsets in effect in June: -09, -08, -04, -09. In 2021a, the expiry of the leapseconds file is 2021-12-28, so the same timestamps would be interpreted according to December offsets: -10, -09, -03, -10.
I must admit I wasn't expecting that. I thought the output would continue as though there would be no changes to the leap seconds in the future.
I agree. For posix/"non-leap" files, faced with a future that is unknown, we do generally continue DST rules into the future, under the assumption that that is more likely to be "less wrong". Truncating the file in this way ensures any region that uses DST will have its far future timestamps be (a) incorrect for roughly half of the year and (b) inconsistently so, since sometimes you'll get the June offset and sometimes you'll get the December offset. That seems "more wrong". -- Tim Parenti
On 3/6/21 8:44 AM, Ian Abbott wrote:
I've just realized that it is normal (as per the zic man page, I think) for the "right" (a.k.a. "leap") zone files to be truncated at the expiry time of the leapseconds file (although the files installed by Debian zic seem to continue beyond the expiry time). I must admit I wasn't expecting that. I thought the output would continue as though there would be no changes to the leap seconds in the future.
Yes, thanks, you've put the finger on the problem. This issue arose due to two changes published in tzdb 2020a. The first change[1] fixed a bug in localtime.c, which mishandled leap seconds after the last explicit transition in a TZif file. The second change[2] truncated files built with -L to when the leap-second table expires; one objective was to work around problems with existing clients with the localtime.c bug. For clients using TZif files with leap second support, we have three objectives: A. Fix and/or work around the longstanding localtime.c bug. B. Clients should be able to deduce when the leap second table expires. C. Clients should be able to predict timestamps after the expiration date more accurately than just "assume the latest-known UTC offset". The second change supported (A) and (B), but broke (C). Given the problems you described, I installed the attached patch, which omits the truncation introduced in tzdb 2020a. This fixes (C), but breaks both (A) and (B). I'll try to think of a better way to support (A) and (B). None of these changes should affect behavior with ordinary TZif files. Only files with leap seconds are affected. [1] Fix leap second bug after last explicit transition. Tue Jan 14 18:15:30 2020 -0800. https://github.com/eggert/tz/commit/fd277c5ca943343072f938f2204a279b29c6fb39 [2] Add support for Expires lines to zic. Tue Jan 14 18:15:30 2020 -0800. https://github.com/eggert/tz/commit/fb434180b191ae0e8d3d17fd7442939d2b563443
On 07/03/2021 02:07, Paul Eggert wrote:
For clients using TZif files with leap second support, we have three objectives:
A. Fix and/or work around the longstanding localtime.c bug.
B. Clients should be able to deduce when the leap second table expires.
C. Clients should be able to predict timestamps after the expiration date more accurately than just "assume the latest-known UTC offset".
The second change supported (A) and (B), but broke (C).
Given the problems you described, I installed the attached patch, which omits the truncation introduced in tzdb 2020a. This fixes (C), but breaks both (A) and (B). I'll try to think of a better way to support (A) and (B).
For (B), would adding an extra leap-second record at the expiry time with no difference in correction value work? That would not conform to RFC 8536, but seems unlikely to break any thing unless that thing is strictly checking that correction values differ by exactly 1. -- -=( 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/12/21 1:55 AM, Ian Abbott wrote:
For (B), would adding an extra leap-second record at the expiry time with no difference in correction value work? That would not conform to RFC 8536, but seems unlikely to break any thing unless that thing is strictly checking that correction values differ by exactly 1.
Exactly my thought. Unfortunately tzcode itself is picky here (because I mistakenly made it picky when helping to write RFC 8536). I doubt whether anyone else is so picky unless they're imitating tzcode itself. That being said, we'll need to be a bit cautious here, and not introduce this change willy-nilly.
On 3/12/21 9:58 AM, Paul Eggert wrote:
On 3/12/21 1:55 AM, Ian Abbott wrote:
For (B), would adding an extra leap-second record at the expiry time with no difference in correction value work? That would not conform to RFC 8536, but seems unlikely to break any thing unless that thing is strictly checking that correction values differ by exactly 1.
Exactly my thought. Unfortunately tzcode itself is picky here (because I mistakenly made it picky when helping to write RFC 8536). I doubt whether anyone else is so picky unless they're imitating tzcode itself. That being said, we'll need to be a bit cautious here, and not introduce this change willy-nilly.
After thinking about it a bit I installed the following patches to implement the above suggestions: https://mm.icann.org/pipermail/tz/2021-March/029934.html https://mm.icann.org/pipermail/tz/2021-March/029940.html Since the affected TZif files do not conform to Internet RFC 8536 it appears we'll need a new TZif version number, version 4, to mark files with this new feature. This new version number will appear only on the problematic files that are generated with leapsecond data that contains an explicit "Expires" line, and such data will not be generated by default. The idea is that TZif version 4 will be documented in an amended version of RFC 8536. Comments welcome as usual.
On Tue, 16 Mar 2021, Paul Eggert via tz wrote:
On 3/12/21 9:58 AM, Paul Eggert wrote:
On 3/12/21 1:55 AM, Ian Abbott wrote:
For (B), would adding an extra leap-second record at the expiry time with no difference in correction value work? That would not conform to RFC 8536, but seems unlikely to break any thing unless that thing is strictly checking that correction values differ by exactly 1.
Exactly my thought. Unfortunately tzcode itself is picky here (because I mistakenly made it picky when helping to write RFC 8536). I doubt whether anyone else is so picky unless they're imitating tzcode itself. That being said, we'll need to be a bit cautious here, and not introduce this change willy-nilly.
After thinking about it a bit I installed the following patches to implement the above suggestions:
https://mm.icann.org/pipermail/tz/2021-March/029934.html https://mm.icann.org/pipermail/tz/2021-March/029940.html
Since the affected TZif files do not conform to Internet RFC 8536 it appears we'll need a new TZif version number, version 4, to mark files with this new feature. This new version number will appear only on the problematic files that are generated with leapsecond data that contains an explicit "Expires" line, and such data will not be generated by default.
How would I be able to generate such a TZif4 file, so that I can test whether timelib can read them correctly? FWIW, timelib doesn't support leapseconds for calculations, but I do need to know whether I can read the files. cheers, Derick -- PHP 7.4 Release Manager Host of PHP Internals News: https://phpinternals.news Like Xdebug? Consider supporting me: https://xdebug.org/support https://derickrethans.nl | https://xdebug.org | https://dram.io twitter: @derickr and @xdebug
On 3/17/21 11:36 AM, Derick Rethans wrote:
How would I be able to generate such a TZif4 file, so that I can test whether timelib can read them correctly? FWIW, timelib doesn't support leapseconds for calculations, but I do need to know whether I can read the files.
You can run 'zic -L leapseconds asia' where leapseconds has an Expires line that is not commented out; this will generate an expiration notice in each TZif file. Alternatively, you can run 'zic -L leapseconds -r@315532800 asia' even without an Expires line. This will generate TZif files with leap second data truncated from below. If you're ignoring leap second data you should be fine; the counts still count the number of leap second entries (which you're skipping over).
participants (11)
-
Andrew Gierth -
Brian Inglis -
Derick Rethans -
Guy Harris -
Ian Abbott -
John Sauter -
Michael H Deckers -
Paul Eggert -
Steve Allen -
Tim Parenti -
汪蒙蒙(木之)