From nobody Sun Feb 5 17:38:49 2023 X-Original-To: bugs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P8xT56HBLz3kdVX for ; Sun, 5 Feb 2023 17:38:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P8xT52VRrz44yL for ; Sun, 5 Feb 2023 17:38:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1675618729; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=IUl/iOSFwv12QwY6d5DsCmozj+wIJiiTxWR7dHkSUao=; b=EKU0rN0JhY7haKwmyT9eJI8uVpxXZmb/oL3k/IDzpiNjGPKs79p/xLi87lUr+yjrIO/xx+ Iyu6hPedmUTHK1kiFHN6Shh6BAYg46TCnW1NUR7AtxwmPt7k9sfOSGWBEc+qTSmz99sSGq /X3WFwF4tvxP3NvF7tp1NcE7PyWSzLdzq4W2fznHsHD+WzBwVOgJAddey6YGWWmDZ+g68S Jl3H4He+dGX2EPhKinuMPzsqAH/CpDSMUU8l9kOBAlUQQFbdwVEw4t49oHc8tMta7YWD15 KV5d6vRZmPWdrduoIG5oq1coNyNvXKKgNkjjIvvauDesS2IJZlQCHOoyt5ow2g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1675618729; a=rsa-sha256; cv=none; b=X7VjpiVI5A4zPuXBxf9Z79jErX7EKRgBX3LBEMtB2B59IpO5Jyyhigz41gOrpXECFC26hC iEml/Vas/ouQCpPnJ7XSla/6z62hpYwCAlRgPBVumAJgNZI97G48kYvuGLbnlDvVp2JfsE rcpJfn/2qi5Q/7nnOtPavJ2dOYcAnRHlGO91eqmHZwtpwdX746hoB102JTvCW9OHo8s6zo m8BndtbXlFfdZXZhDBjlDH8eflGeytcpph0ZhlO6qd9bDZR04fVQVS/pWLDcnpHmAS1jTo u99dNDcs6ZEimvFlMP6f/ghLMYV1zTED3mI/QaDStkICWrbSfQVxgA5CUxDmEA== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4P8xT51SSmz13Yc for ; Sun, 5 Feb 2023 17:38:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 315HcnHI027434 for ; Sun, 5 Feb 2023 17:38:49 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 315HcnnB027433 for bugs@FreeBSD.org; Sun, 5 Feb 2023 17:38:49 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 269342] historical tzdata lost for many zones following 2021/2022 IANA tz changes Date: Sun, 05 Feb 2023 17:38:49 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: fbsd@opal.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Bug reports List-Archive: https://lists.freebsd.org/archives/freebsd-bugs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-bugs@freebsd.org MIME-Version: 1.0 X-ThisMailContainsUnwantedMimeParts: N 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.=