Date: Sun, 05 Feb 2023 17:38:49 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 269342] historical tzdata lost for many zones following 2021/2022 IANA tz changes Message-ID: <bug-269342-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D269342 Bug ID: 269342 Summary: historical tzdata lost for many zones following 2021/2022 IANA tz changes Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: bugs@FreeBSD.org Reporter: fbsd@opal.com During 2021 and 2022, the IANA timezone data [IANA-TZ] was changed to link = many zones together if their timezone rules have been the same since the 1970 UN= IX Epoch. This has led to two undesirable consequences: 1. For many countries/regions, the timezone data is now taken from another country's/region's definition, resulting in their timezone name confusingly being reflected as that of the other country/region. For example, the following are now all linked to Europe/Berlin: Arctic/Longyearbyen Europe/Copenhagen Europe/Oslo Europe/Stockholm Atlantic/Jan_Mayen Functions that look up the local timezone name now report "Europe/Berlin" for users in any of these linked countries/regions. There are now many such linked regions. Another example: Icelandic users= now see their zone name as "Africa/Abidjan" instead of the expected "Atlantic/Reykjavik". The standard/daylight rules are consistent for these since 1970, so user= s do see the correct time, even though the zone name is not as expected. 2. For applications that use dates PRIOR to the 1970 Epoch, historical standard/daylight rule information for each country/region is now lost, it = now being taken from the common zone's definition. Even though the linked zones' rules have been consistent since 1970, their rules are very likely to have = been different PRIOR to 1970. While that data still exists in the tzdata databas= e, it is no longer installed and so no longer accessible to applications. Applications presenting historical dates/times may therefore reflect incorr= ect timezones for linked regions. There has been debate on the IANA timezone lists as to whether these linked zones were a good idea. There appear to have been two solutions to allow systems to revert to installing the historical data for each region: A. The forked global-tz database [GLOBAL-TZ] which mirrors the IANA data but which installs zones without links and keeps each zone's historical data. B. New settings in the IANA tzdata Makefile, PACKRATDATA and PACKRATLIST, which, the comment says, cause the data to be installed the same way as global-tz does. It is necessary to set: PACKRATDATA=3D backzone PACKRATLIST=3D zone.tab I would like to propose that FreeBSD reverts to installing historical data = for each country/region so that both issues 1. and 2. above are corrected. The simplest solution would appear to be to set the two PACKRAT variables in src/contrib/tzdata/Makefile as shown in B. [IANA-TZ] https://github.com/eggert/tz [GLOBAL-TZ] https://github.com/JodaOrg/global-tz --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-269342-227>