- tz - lists.iana.org

Single source of truth for timezone data
by Benjamin Drung Dec. 11, 2022

Dec. 11, 2022

Hi everyone, I am writing this mail with my distribution maintainer hat on since I am responsible for keeping the tzdata package up-to-date in Ubuntu. I like to propose to have a single source of truth for timezone data, which should be the tzdata source package. Updating this package in a distribution like Debian/Ubuntu should be enough to update all consumers in the distribution. Sadly this is currently not the case. Ubuntu since 20.04 (focal) adds the four icu source files metaZones.txt, timezoneTypes.txt, windowsZones.txt, and zoneinfo64.txt from https://github.com/unicode-org/icu-data to the tzdata source package. Then it uses genrb and icupkg to generate the .res files. Since the icu project lacks behind the tzdata release by hours up to days, Ubuntu has to update tzdata twice (first the tzdata release, then the icu update). metaZones.txt, timezoneTypes.txt, and windowsZones.txt are generated using tools/cldr/cldr-to-icu/build-icu-data.xml from https://github.com/unicode-org/icu. zoneinfo64.txt is generated by tz2icu. build-icu-data.xml uses https://github.com/unicode-org/cldr as input to convert the cldr data to icu. If I saw that correctly, only common/supplemental/metaZones.xml needs to be updated there on an update. Can tzdata include the necessary data and tools to generate metaZones.xml from its source? Then it would be possible to generate the icu data from the tzdata source without the need to wait for icu to catch up. Then Debian/Ubuntu can ship a tzdata-icu package for it [1]. [1] https://bugs.debian.org/954112 -- Benjamin Drung Debian & Ubuntu Developer

9 23

Error in America/Ojinaga
by Nikos (Nikolaos) Papadakos, PhD Dec. 10, 2022

Dec. 10, 2022

Hello, We are suspecting that your timezone update tzdb 2022g is incorrectly accounting for America/Ojinaga. Our customer is a major airline in Mexico and they tell me the time should America/Ojinaga should be the same as America/Denver. They provide as evidence official announcements in Spanish language. For example: https://www.dof.gob.mx/nota_detalle.php?codigo=5672650&fecha=29/11/2022#gsc… which says: "Artículo 5. III. Para el Estado de Baja California, así como para los municipios de Janos, Ascensión, Juárez, Praxedis G. Guerrero y Guadalupe, del Estado de Chihuahua, acorde a sus correlativos a su franja fronteriza, se aplica el meridiano 105 grados al oeste de Greenwich." I don't speak Spanish to be honest, my customer does. In the above the phrase seems to be "Juárez [...] del Estado de Chihuahua" which isreferring specifically to Ciudad Juárez in the State of Chihuahua. And then it says "el meridiano 105 grados al oeste de Greenwich" giving the degrees from Greenwich. They've given me some other references, but the above seems the most official. I would like to ask you to please double check which one is the correct. Best regards, Nikos P.S.: Please do not use my name or my company's name.

2 2

Re: [tz] Error in America/Ojinaga
by Brian Inglis Dec. 10, 2022

Dec. 10, 2022

On 2022-12-09 15:11, Tim Parenti via tz wrote: > On Fri, 9 Dec 2022 at 16:46, Nikos (Nikolaos) Papadakos, PhD wrote: >> Our customer is a major airline in Mexico and they tell me the time >> should America/Ojinaga should be the same as America/Denver. > It is our understanding that the recent changes split time zone observances > along Chihuahua's northern border. According to that split, from 2022-11-30, > Ojinaga is like America/Chicago, while Ciudad Juárez is like America/Denver. >> III. Para el Estado de Baja California, así como para los municipios >> de Janos, Ascensión, Juárez, Praxedis G. Guerrero y Guadalupe, del >> Estado de Chihuahua, acorde a sus correlativos a su franja fronteriza, >> se aplica el meridiano 105 grados al oeste de Greenwich." > While the above describes that the municipio of Juárez (including its municipal > seat, Ciudad Juárez) observes a standard time of UTC-7, which is like > America/Denver, the section immediately prior reads: > II. Para los municipios de Coyame del Sotol, Ojinaga y Manuel Benavides, > del Estado de Chihuahua, acorde a sus correlativos a su franja fronteriza, > se aplica el meridiano 90 grados al oeste de Greenwich; > …meaning that the city and municipio of Ojinaga follow UTC-6, which is like > America/Chicago. > A new zone, America/Ciudad_Juarez, was split off from America/Ojinaga in 2022g > to allow for these differences in timekeeping. Since this zone did not exist > prior to 2022g, those in the western portions of Chihuahua's border region > (including Juárez) will need to switch to it, as the time in and around Juárez > and Chihuahua's northwest no longer matches the time in Ojinaga and Chihuahua's > northeast. Nor the time in Chihuahua's interior which is on CST like Ojinaga. The airline can check the IATA SSIM Schedule Time Zones for CUU/MMC Chihuahua and CJS/MMCS Ciudad Juarez to confirm the changes (Ojinaga has no airport). -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry

1 0

Re: [tz] Single source of truth for timezone data
by Brian Inglis Dec. 9, 2022

Dec. 9, 2022

On 2022-12-08 13:50, Paul Eggert via tz wrote: > On 2022-12-08 05:24, Almaz Mingaleev wrote: >>>> new timezone abbreviation "XYT", downstream distros like Ubuntu can >>>> immediately ship the new P without waiting for i18n updates. P will >> It is not a problem if a distro ships it, it is a problem if this new >> stuff leaks to the external world. > Sorry, I'm not following. When Ubuntu ships a new tzdata package then surely > that has "leaked" to the outside world? >> It would be naive to expect from a user base of a service to have >> up-to-date time zone data even after a month after TZDB release. > In the past I've gotten my Ubuntu systems updated within 24 hours of a tzdata > release, simply by applying patches as usual from Ubuntu. But as Benjamin > indicates, this is not happening with 2022g. I just now checked for updates and > I'm still stuck on 2022f. So from my point of view, Ubuntu is slow in this case > - instead of taking less than a day, it's taking more than a week. >> being consistently wrong about _new_ changes is better >> than having different answers within the platform. > As a Ubuntu user, I'd prefer tzdata to be up-to-date even though ICU is > out-of-date, over having both tzdata and ICU out-of-date. Of course Ubuntu > differs from Android in that most apps use tzdata not ICU. Still, I'm a bit > curious what end-user-visible problems would occur on Android and/or Ubuntu if > tzdata leads ICU slightly. I know you've seen problems, but were they end-user > problems or just test-case problems? On Ubuntu various other copies of tzdata > (e.g., Python's) can be slightly out of date too, but this doesn't seem to be > much of an issue. >> It is not translations that we are waiting for, but changes like [1 >> <https://github.com/unicode-org/icu/pull/2261/files>]. Recent time zone >> changes were short notice ones and ICU team (thanks Yoshito and others!) >> did these changes very quickly. > Thanks, I didn't know that. > Here's a timeline I see for the latest Mexico change: > * 2022-11-28 17:00 UTC - news article published announcing the change (which is > not official yet, I think) > <http://puentelibre.mx/noticia/ciudad_juarez_cambio_horario_noviembre_2022/> > * 2022-11-29 03:55:31 UTC - tz mailing list notified > <https://mm.icann.org/pipermail/tz/2022-November/032365.html> > * 2022-11-29 17:42:29 UTC (14 hours after notification) - tzdb 2022g announced > <https://mm.icann.org/pipermail/tz-announce/2022-November/000076.html> > * 2022-11-29 18:23:41 UTC (less than an hour after tzdb 2022g announcement) > tzdata 2022g-r0 released for Alpine Linux > <https://pkgs.alpinelinux.org/package/edge/main/x86/tzdata> > * 2022-11-30 07:06 UTC (7 hours after tzdb 2022g announcement) - tzdata 2022g-1 > released for Arch Linux <https://archlinux.org/packages/core/x86_64/tzdata/> > * 2022-12-01 03:08:08 UTC (33 hours after tzdb 2022g announcement) - > abovementioned ICU patch committed > * 2022-12-01 12:38:06 UTC (9 hours after ICU patch committed) - Ubuntu patch > committed <https://launchpad.net/ubuntu/+source/tzdata/2022g-0ubuntu0.22.10.1> > * 2022-12-05 (4 days after ICU patch committed) - Red Hat Enterprise Linux fix > available to users <https://access.redhat.com/errata/RHBA-2022:8785> > * 2022-12-07 (6 days after ICU patch committed) - Android patch committed > <https://android.googlesource.com/platform/system/timezone/+/ea3e0ece71974c1…> > * now (a week after ICU patch committed) - my Ubuntu workstation is still not > updated. > We should be able to do better than this; that is, be more like Alpine or Arch > Linux, or at least more like RHEL (though I see that Fedora still hasn't > released 2022g...). Though ICU is part of the problem (as is tzdb itself :-), > most of the delay seems to be occurring even after ICU patches are applied. Launchpad shows Ubuntu 22.10 Proposed kinetic-proposed/main tzdata 2022g, also jammy- and focal-proposed, released Dec 1 when the maintainer started this thread. You could add the -proposed source to apt sources, and/or set apt preferences to only use it for tzdata, as the -proposed source seems to be first to get ICU updates in tzdata package release yyyyX-0ubuntu0.MM.mm.1; -updates and -security follow. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry

1 0

[PROPOSED] America/Yellowknife now links to America/Edmonton
by Paul Eggert Dec. 9, 2022

Dec. 9, 2022

(Thanks to Almaz Mingaleev.) * NEWS: Mention this. * backzone (America/Yellowknife): Move Zone here ... * northamerica: ... from here. * zone.tab, zone1970.tab: Remove America/Yellowknife. --- NEWS | 8 ++++++++ backzone | 5 +++++ northamerica | 7 ------- zone.tab | 3 +-- zone1970.tab | 3 +-- 5 files changed, 15 insertions(+), 11 deletions(-) diff --git a/NEWS b/NEWS index ac0b611a..98cc14f7 100644 --- a/NEWS +++ b/NEWS @@ -4,6 +4,7 @@ Unreleased, experimental changes Briefly: Much of Greenland still uses DST from 2024 on. + America/Yellowknife now links to America/Edmonton. The code now defaults to C99 or later. Fix use of C23 attributes. @@ -17,6 +18,13 @@ Unreleased, experimental changes This change from 2022g doesn't affect timestamps until 2024-03-30, and doesn't affect tm_isdst until 2023-03-25. + Changes to past timestamps + + America/Yellowknife has changed from a Zone to a backward + compatibility Link, as it no longer differs from America/Edmonton + since 1970. (Thanks to Almaz Mingaleev.) This affects some + pre-1948 timestamps. The old data are now in 'backzone'. + Changes to code The code by default is now designed for C99 or later. To build in diff --git a/backzone b/backzone index 7803c57d..1bd23ac6 100644 --- a/backzone +++ b/backzone @@ -928,6 +928,11 @@ Zone America/Thunder_Bay -5:57:00 - LMT 1895 Zone America/Tortola -4:18:28 - LMT 1911 Jul # Road Town -4:00 - AST +# Yellowknife, Northwest Territories +Zone America/Yellowknife 0 - -00 1935 # Yellowknife founded? + -7:00 NT_YK M%sT 1980 + -7:00 Canada M%sT + # Dumont d'Urville, Île des Pétrels, -6640+14001, since 1956-11 # <https://en.wikipedia.org/wiki/Dumont_d'Urville_Station> (2005-12-05) # diff --git a/northamerica b/northamerica index e33701bf..24b68e72 100644 --- a/northamerica +++ b/northamerica @@ -2125,10 +2125,6 @@ Zone America/Fort_Nelson -8:10:47 - LMT 1884 # Nunavut ... moved ... to incorporate the whole territory into one time zone. # Nunavut moves to single time zone Oct. 31 # http://www.nunatsiaq.com/nunavut/nvt90903_13.html -# -# From Antoine Leca (1999-09-06): -# We then need to create a new timezone for the Kitikmeot region of Nunavut -# to differentiate it from the Yellowknife region. # From Paul Eggert (1999-09-20): # Basic Facts: The New Territory @@ -2322,9 +2318,6 @@ Zone America/Cambridge_Bay 0 - -00 1920 # trading post est.? -5:00 - EST 2000 Nov 5 0:00 -6:00 - CST 2001 Apr 1 3:00 -7:00 Canada M%sT -Zone America/Yellowknife 0 - -00 1935 # Yellowknife founded? - -7:00 NT_YK M%sT 1980 - -7:00 Canada M%sT Zone America/Inuvik 0 - -00 1953 # Inuvik founded -8:00 NT_YK P%sT 1979 Apr lastSun 2:00 -7:00 NT_YK M%sT 1980 diff --git a/zone.tab b/zone.tab index 6e5adb9f..5d5c79ff 100644 --- a/zone.tab +++ b/zone.tab @@ -121,9 +121,8 @@ CA +744144-0944945 America/Resolute Central - NU (Resolute) CA +624900-0920459 America/Rankin_Inlet Central - NU (central) CA +5024-10439 America/Regina CST - SK (most areas) CA +5017-10750 America/Swift_Current CST - SK (midwest) -CA +5333-11328 America/Edmonton Mountain - AB; BC (E); SK (W) +CA +5333-11328 America/Edmonton Mountain - AB; BC (E); NT (E); SK (W) CA +690650-1050310 America/Cambridge_Bay Mountain - NU (west) -CA +6227-11421 America/Yellowknife Mountain - NT (central) CA +682059-1334300 America/Inuvik Mountain - NT (west) CA +4906-11631 America/Creston MST - BC (Creston) CA +5546-12014 America/Dawson_Creek MST - BC (Dawson Cr, Ft St John) diff --git a/zone1970.tab b/zone1970.tab index a9b36d36..819316be 100644 --- a/zone1970.tab +++ b/zone1970.tab @@ -108,9 +108,8 @@ CA +744144-0944945 America/Resolute Central - NU (Resolute) CA +624900-0920459 America/Rankin_Inlet Central - NU (central) CA +5024-10439 America/Regina CST - SK (most areas) CA +5017-10750 America/Swift_Current CST - SK (midwest) -CA +5333-11328 America/Edmonton Mountain - AB; BC (E); SK (W) +CA +5333-11328 America/Edmonton Mountain - AB; BC (E); NT (E); SK (W) CA +690650-1050310 America/Cambridge_Bay Mountain - NU (west) -CA +6227-11421 America/Yellowknife Mountain - NT (central) CA +682059-1334300 America/Inuvik Mountain - NT (west) CA +5546-12014 America/Dawson_Creek MST - BC (Dawson Cr, Ft St John) CA +5848-12242 America/Fort_Nelson MST - BC (Ft Nelson) -- 2.37.2

2 2

[PROPOSED] Try to check longstanding padding assumptions
by Paul Eggert Dec. 8, 2022

Dec. 8, 2022

This is helpful only when porting to oddball platforms in some situations where time_t is signed and has padding bits. (Even C23 allows these platforms.) Formerly tzcode would silently have undefined runtime behavior on such platforms; with this patch, there is likely a compile-time diagnostic instead. * private.h (static_assert): New macro, defined for pre-C23 compilers. (SIGNED_PADDING_CHECK_NEEDED): New constant. Try to check that TIME_T_MIN and TIME_T_MAX are actually the min and max time_t values. --- private.h | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/private.h b/private.h index 1d6ddf7..7ddf4e5 100644 --- a/private.h +++ b/private.h @@ -43,6 +43,10 @@ # include <stdbool.h> #endif +#if __STDC_VERSION__ < 202311 +# define static_assert(cond) extern int static_assert_check[(cond) ? 1 : -1] +#endif + /* ** zdump has been made independent of the rest of the time ** conversion package to increase confidence in the verification it provides. @@ -833,10 +837,23 @@ ATTRIBUTE_REPRODUCIBLE time_t time2posix_z(timezone_t, time_t); int: INT_MAX, long: LONG_MAX, long long: LLONG_MAX, \ default: TIME_T_MAX_NO_PADDING) \ : (time_t) -1) +enum { SIGNED_PADDING_CHECK_NEEDED + = _Generic((time_t) 0, + signed char: false, short: false, + int: false, long: false, long long: false, + default: true) }; #else # define TIME_T_MIN TIME_T_MIN_NO_PADDING # define TIME_T_MAX TIME_T_MAX_NO_PADDING -#endif +enum { SIGNED_PADDING_CHECK_NEEDED = true }; +#endif +/* Try to check the padding assumptions. Although TIME_T_MAX and the + following check can both have undefined behavior on oddball + platforms due to shifts exceeding widths of signed integers, these + platforms' compilers are likely to diagnose these issues in integer + constant expressions, so it shouldn't hurt to check statically. */ +static_assert(! TYPE_SIGNED(time_t) || ! SIGNED_PADDING_CHECK_NEEDED + || TIME_T_MAX >> (TYPE_BIT(time_t) - 2) == 1); /* ** 302 / 1000 is log10(2.0) rounded up. -- 2.38.1

1 0

[PROPOSED] Update city lists in theory.html
by Paul Eggert Dec. 7, 2022

Dec. 7, 2022

* theory.html: Update xMT city lists to match what’s currently generated by the default build. --- theory.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/theory.html b/theory.html index 6a39ce7a..fbbb9e47 100644 --- a/theory.html +++ b/theory.html @@ -494,7 +494,7 @@ in decreasing order of importance: These abbreviations are: AMT Asunción, Athens; - BMT Baghdad, Bangkok, Batavia, Bermuda, Bern, Bogotá, Bridgetown, + BMT Baghdad, Bangkok, Batavia, Bermuda, Bern, Bogotá, Brussels, Bucharest; CMT Calamarca, Caracas, Chisinau, Colón, Córdoba; DMT Dublin/Dunsink; @@ -506,7 +506,7 @@ in decreasing order of importance: IMT Irkutsk, Istanbul; JMT Jerusalem; KMT Kaunas, Kyiv, Kingston; - LMT Lima, Lisbon, local, Luanda; + LMT Lima, Lisbon, local; MMT Macassar, Madras, Malé, Managua, Minsk, Monrovia, Montevideo, Moratuwa, Moscow; PLMT Phù Liễn; -- 2.37.2

1 0

[PATCH] Update abbreviation lists in theory.html
by Paul Eggert Dec. 7, 2022

Dec. 7, 2022

* theory.html: Update abbreviation lists to match what’s currently generated by the default build. --- theory.html | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/theory.html b/theory.html index f2b798be..6a39ce7a 100644 --- a/theory.html +++ b/theory.html @@ -443,11 +443,11 @@ in decreasing order of importance: CAT/CAST Central Africa, CET/CEST/CEMT Central European, ChST Chamorro, - CST/CDT/CWT/CPT/CDDT Central [North America], + CST/CDT/CWT/CPT Central [North America], CST/CDT China, GMT/BST/IST/BDST Greenwich, EAT East Africa, - EST/EDT/EWT/EPT/EDDT Eastern [North America], + EST/EDT/EWT/EPT Eastern [North America], EET/EEST Eastern European, GST/GDT Guam, HST/HDT/HWT/HPT Hawaii, @@ -460,13 +460,13 @@ in decreasing order of importance: MET/MEST Middle European (a backward-compatibility alias for Central European), MSK/MSD Moscow, - MST/MDT/MWT/MPT/MDDT Mountain, + MST/MDT/MWT/MPT Mountain, NST/NDT/NWT/NPT/NDDT Newfoundland, NST/NDT/NWT/NPT Nome, NZMT/NZST New Zealand through 1945, NZST/NZDT New Zealand 1946–present, PKT/PKST Pakistan, - PST/PDT/PWT/PPT/PDDT Pacific, + PST/PDT/PWT/PPT Pacific, PST/PDT Philippine, SAST South Africa, SST Samoa, @@ -512,6 +512,7 @@ in decreasing order of importance: PLMT Phù Liễn; PMT Paramaribo, Paris, Perm, Pontianak, Prague; PMMT Port Moresby; + PPMT Port-au-Prince; QMT Quito; RMT Rangoon, Riga, Rome; SDMT Santo Domingo; @@ -519,8 +520,7 @@ in decreasing order of importance: SMT Santiago, Simferopol, Singapore, Stanley; TBMT Tbilisi; TMT Tallinn, Tehran; - WMT Warsaw; - ZMT Zomba. + WMT Warsaw. -- 2.37.2

1 0

Re: [tz] TZDB patches, UTF-8, and Microsoft Exchange
by Brian Inglis Dec. 4, 2022

Dec. 4, 2022

On 2022-12-04 12:48, Fred Gleason via tz wrote: > On Dec 2, 2022, at 17:21, Derick Rethans via tz <tz(a)iana.org > <mailto:tz@iana.org>> wrote: > >> This problem would go away if you'd except change requests through GitHub's >> pull request feature. > > I for one heartily second this suggestion. While I understand that this can be a > sensitive issue for some long-time contributors here, given the composition of > TZDB’s audience (veteran coders plus the occasional technically > non-sophisticated user), I think anything that simplifies the overall workflow > while making the process more transparent to non-coders would be a net win. > > >> It's quite a common and modern method to propose changes to open source >> software, that I'd expect many would already be familiar with. > > I agree. The GitHub pull request process has become a sort of _lingua franca_ in > the code development realm, arguably more so than any other single methodology > for managing distributed open source development. In that context, the current > _status quo_ is rather *anti*-user friendly in the sense that many coders, when > first encountering the TZDB GitHub repo think that they already know how to > generate and submit patches; only later discovering that they in fact don’t, > since what is arguably the central workflow metaphor of what makes GitHub useful > has (seemingly inexplicably) been switched off. > > On the basis of the patches I’ve seen go by on this listserv over the past few > years, it would also seem that “easing/reducing maintenance burden” has become a > major goal for TZDB. Given that, I would respectfully argue that moving to a > PR-based workflow would do more towards that end than any number of minor code > polishing changes. > > > On Dec 2, 2022, at 17:43, Paul Eggert via tz <tz(a)iana.org <mailto:tz@iana.org>> > wrote: > >> Yes, but GitHub has its own problems. I'd rather stick with email, just as >> many other projects use email for this sort of thing. > > Well, this one at least does. FWIW, none of the other FOSS projects whose dev > lists I follow use the traditional patches-via-email workflow any more. While by > no means all of them use GitHub, what they all do use is some sort of system > that provides automated patch generation/testing/merging along with a GUI option > that allows non-coder types some level of visibility into the process. > > >> Also, I've been thinking of moving the development repository off GitHub for >> other reasons, and I don't want to rely on GitHub-specific features. > > Would you care to share with us what some of those “other reasons” might be? At a guess, I'd imagine for a multi-GNU project contributor, even using a proprietary vendor locked-in (and potentially future deprecated or locked-out) platform might be an issue (possibly queried only in person or private DM), as it is for many other open source contributors, where even mentioning GitHub evokes a spit-blah *NEVER* response, and moving to GH would result in losing some contributions. For some open-source projects, GH is used only as a public and backup repo for their primary dev workflows, as are sv.gnu.org and sv.non-gnu.org in some cases. A number are using in-house and/or public GitLab instances, and others have surfaced their email with public-inbox like https://lore.kernel.org/ where issues and patches can be handled using workflow tools like https://git.kernel.org/pub/scm/utils/b4/b4.git It would be good if the IETF, IANA, and/or ICANN made their email available in such searchable archives, an area where tz is currently lacking. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry

1 0

[PATCH] Fix America/Nuuk timezone change
by Thomas M. Steenholdt Dec. 4, 2022

Dec. 4, 2022

Fix the upcoming move of America/Nuuk from normaltime -03 to -02, according to the passed bill. --- europe | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/europe b/europe index a3547b4f..71ea3ab2 100644 --- a/europe +++ b/europe @@ -1126,6 +1126,21 @@ Zone Atlantic/Faroe -0:27:04 - LMT 1908 Jan 11 # Tórshavn # "bekymringer" URL says the intent is no transition March 25, that # Greenland will not go back to winter time in fall 2023, and that # only America/Nuuk is affected (though further changes may occur). +# +# From Thomas M. Steenholdt (2022-12-02): +# Processing of the bill is documented here: +# https://ina.gl/samlinger/oversigt-over-samlinger/samling/dagsordener/dagsor… +# Notably: +# - The bill to move America/Nuuk from UTC-03 to UTC-02 passed. +# - The bill to stop observing DST did not (Greenland will stop observing DST +# when EU does). +# Details on the implementation are here (section 6): +# https://ina.gl/dvd/EM%202022/pdf/media/2553529/pkt17_em2022_tidens_bestemme… +# This is how the change will be implemented: +# 1. The shift *to* DST in 2023 happens as normal. +# 2. The shift *from* DST in 2023 happens as normal, but coincides with the +# shift to UTC-02 normaltime (people will not change their clocks here). +# 3. After this, DST is still observed, but as -02/-01 instead of -03/-02. # Rule NAME FROM TO - IN ON AT SAVE LETTER/S Rule Thule 1991 1992 - Mar lastSun 2:00 1:00 D @@ -1149,8 +1164,8 @@ Zone America/Scoresbysund -1:27:52 - LMT 1916 Jul 28 # Ittoqqortoormiit -1:00 EU -01/+00 Zone America/Nuuk -3:26:56 - LMT 1916 Jul 28 # Godthåb -3:00 - -03 1980 Apr 6 2:00 - -3:00 EU -03/-02 2023 Mar 25 22:00 - -2:00 - -02 + -3:00 EU -03/-02 2023 Oct 28 23:00 + -2:00 EU -02/-01 Zone America/Thule -4:35:08 - LMT 1916 Jul 28 # Pituffik -4:00 Thule A%sT -- 2.34.1

5 7