[PATCH] Fix America/Nuuk timezone change
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/dagsord... +# 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_bestemmel... +# 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
Thanks for the heads-up and the patch. I installed the attached, which differs in commentary and minor details, as it excises some now-obsolete commentary, adds a NEWS item, and uses EU-style UTC transition times.
By the way, I had a little trouble applying your Greenland patch, because it was encoded in ISO 8859-1, and even though its email header line correctly said 'Content-Type: text/plain; charset="iso-8859-1"', Git understandably took alarm at the mixture of the patch's ISO 8859-1 and tzdata's UTF-8 and refused to apply the patch. As it turned out I needed to edit the patch anyway so this was only a minor hiccup. Still, it looks like this could be a systematic problem with Microsoft Outlook and/or Exchange, and I wonder whether we can briefly advise Microsoft-using patch-senders to avoid future glitches. Unfortunately I don't use Microsoft software for email and so don't know what to suggest. Would it suffice to say "Please use 'git send-email'", or would that not work because Microsoft Exchange transcodes email from UTF-8 into ISO 8859-1? Does Microsoft Exchange transcode attachments, so even "Please send the patch as an attachment" does not work? Or was the problem here that Microsoft Outlook transcodes outgoing mail, and if so can this be fixed by asking users to specify UTF-8 encoding for outgoing messages at File > Options > Advanced > International options[1]? Any suggestions would be welcome. [1]: https://learn.microsoft.com/en-us/exchange/mail-flow/content-conversion/mess...
On 2 December 2022 22:09:41 GMT, Paul Eggert via tz <tz@iana.org> wrote:
By the way, I had a little trouble applying your Greenland patch, because it was encoded in ISO 8859-1, and even though its email header line correctly said 'Content-Type: text/plain; charset="iso-8859-1"', Git understandably took alarm at the mixture of the patch's ISO 8859-1 and tzdata's UTF-8 and refused to apply the patch.
This problem would go away if you'd except change requests through GitHub's pull request feature. 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. cheers Derick
On 12/2/22 14:21, Derick Rethans wrote:
By the way, I had a little trouble applying your Greenland patch, because it was encoded in ISO 8859-1...
This problem would go away if you'd except change requests through GitHub's pull request feature.
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. 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. Fewer and fewer programs default to ISO 8859 these days, so any advice we'd add would be for a dwindling number of old-fashioned clients. We shouldn't need to change the development process for them.
On Dec 2, 2022, at 17:21, Derick Rethans via tz <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@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? Cheers! |---------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |---------------------------------------------------------------------| | The greatest obstacle to discovery is not ignorance -- it is the | | illusion of knowledge. | | | | -- Daniel J. Boorstin | | "The Discoverers" | |---------------------------------------------------------------------|
Paul Eggert wrote:
Still, it looks like this could be a systematic problem with Microsoft Outlook and/or Exchange, and I wonder whether we can briefly advise Microsoft-using patch-senders to avoid future glitches. Unfortunately I don't use Microsoft software for email and so don't know what to suggest.
Outlook and Exchange are fully capable of working in UTF-8, but Outlook doesn’t insist on it, and might not even default to it. I seem to remember having to change the send and receive settings away from “Western European (Windows)” (code page 1252, similar to ISO 8859-1) many years ago. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org
Sorry about that. In my experience, Office 365 can be a pain in the neck for something like this. Getting a cli mailer set up for 'git send-email' is non-trivial with oauth2 requirements etc. It can be done for sure, but it used to be a whole lot simpler. I tend to simply use the web client, which appears to then mess with the encoding, and with seemingly no way to change that. I should probably just have attached the patch, rather than in-lining it. I believe that would have prevented the problem. (FWIW, this mail is sent with Thunderbird instead) On 02/12/2022 19.09, Paul Eggert wrote:
By the way, I had a little trouble applying your Greenland patch, because it was encoded in ISO 8859-1, and even though its email header line correctly said 'Content-Type: text/plain; charset="iso-8859-1"', Git understandably took alarm at the mixture of the patch's ISO 8859-1 and tzdata's UTF-8 and refused to apply the patch.
As it turned out I needed to edit the patch anyway so this was only a minor hiccup. Still, it looks like this could be a systematic problem with Microsoft Outlook and/or Exchange, and I wonder whether we can briefly advise Microsoft-using patch-senders to avoid future glitches. Unfortunately I don't use Microsoft software for email and so don't know what to suggest.
Would it suffice to say "Please use 'git send-email'", or would that not work because Microsoft Exchange transcodes email from UTF-8 into ISO 8859-1?
Does Microsoft Exchange transcode attachments, so even "Please send the patch as an attachment" does not work?
Or was the problem here that Microsoft Outlook transcodes outgoing mail, and if so can this be fixed by asking users to specify UTF-8 encoding for outgoing messages at File > Options > Advanced > International options[1]?
Any suggestions would be welcome.
[1]: https://learn.microsoft.com/en-us/exchange/mail-flow/content-conversion/mess...
participants (5)
-
Derick Rethans -
Doug Ewell -
Fred Gleason -
Paul Eggert -
Thomas M. Steenholdt