[tz] zoneinfo generating issues

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Wed Mar 3 16:45:04 UTC 2021


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


More information about the tz mailing list