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.

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

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 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 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 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.]

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 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 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 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).