March 2022 - tz - lists.iana.org

Re: [tz] Unexpected last transition in Africa/Casablanca
by Kerry Shetline March 23, 2022

March 23, 2022

This image might make the issue clearer: https://i.imgur.com/6PFLDeWh.png What happened is that what used to be called DST is now considered the standard time for this timezone, and what used to be standard time is now *negative* DST. > Here are the last transitions in Africa/Casablanca output (rearguard > format): > > transition,type,[UTC time],[Type offset],[Type isDST] > 3672612000,1,2086-05-19T02:00:00Z,PT1H,DST > 3699828000,2,2087-03-30T02:00:00Z,PT0S,STD > 3703456800,3,2087-05-11T02:00:00Z,PT1H,STD > > So change is from standard to standard, even though offset changes from 0h > to 1h. Is that expected behaviour?

2 1

zic man page vs RFC8536
by Almaz Mingaleev March 22, 2022

March 22, 2022

Man page says that AT can be "260:00" [1]. Though in the RFC hour part in the footer is in [-167, 167] range [2]. Is man page information correct / safe to use? Thanks, Almaz [1] https://github.com/eggert/tz/blob/64c5d196f739b7662497b0986d4d94c418a3fd85/… [2] https://datatracker.ietf.org/doc/html/rfc8536#section-3.3.1

2 1

Announcing global-tz - 2022ag (beta)
by Stephen Colebourne March 21, 2022

March 21, 2022

As regular readers of this list will be aware, there is a long-running dispute about the contents of the IANA time-zone database. (See the list history for details on the dispute). As previously discussed, and given the unwillingness of the tz-coordinator to alter his opinion in any way, it is unfortunately the case that a fork of tzdb is required. I have created such a fork, one that is intended to be as directly derivable from iana-tz as possible so that iana-tz itself can still be the golden source for the raw data. https://github.com/JodaOrg/global-tz The basic rules guiding the data that global-tz includes are: * An identifier for each region of the world where clocks have differed since 1970-01-01. * At least one identifier for each inhabited ISO 3166-1 code. * For these identifiers the data returned shall be the best available, including pre-1970 history. The first release of the fork is 2022ag-beta1, which will become the final 2022ag release tomorrow if there are no major issues or objections. https://github.com/JodaOrg/global-tz/releases/tag/2022ag-beta1 The approach taken is to copy data from backzone and put it back into the main files. This recreates tzdb as it would have been had the damaging changes since 2014 not been made. The process is *automated*. A GitHub Action script runs a few times a day that reads the iana-tz repo and runs a script that moves data from backzone to the appropriate main file. The result is an iana-tz compatible source code repo: Output tzdb source files: https://github.com/JodaOrg/global-tz/tree/global-tz Comparison between iana-tz and global-tz: https://github.com/JodaOrg/global-tz/compare/iana-tz...global-tz Genaration script: https://github.com/JodaOrg/global-tz/blob/main/actions.txt https://github.com/JodaOrg/global-tz/blob/main/GlobalTzMain.java The only maintenance that the fork should need is if iana-tz removes further pre-1970 history. Downstream consumers should be able to take the generated source code (either from the global-tz branch or the released tar.gz file) and consume it as they would have consumed an iana-tz release. Joda-Time and threeTen-Backport will be using global-tz going forward. Please can I ask anyone that is interested to test out the 2022ag-beta1 release before I make it final. PRs / Issues are welcome, provided they relate to aspects under the control of global-tz. thanks Stephen

7 13

Re: [tz] Review incorrect man-pages commit
by Alejandro Colomar (man-pages) March 20, 2022

March 20, 2022

Hi, Branden! On 3/20/22 11:52, G. Branden Robinson wrote: > > Sure! The punctuation does get a bit bewildering. > [...] Thanks for the great explanation! > > Now, for the part people actually care about, which is how to fix it: > take the escape character off of that `. > > You thus want > > +to "\fI[a\('a\(`a\(:a\(^a]\fP", that is, I applied a patch with this. > > If you wanted to write this without using any aliases, you could adopt > groff syntax. > > +to "\fI[a\[a aa]\[a ga]\[a ad]\[a a^]\fP", that is, I'm going to hold this for later, so that we decide globally how to format all pages, and not just this one. I prefer global consistency here. > > I don't know if people regard that as more or less impenetrable. It is > more _flexible_, and admits usage of diacritics/combining characters not > envisioned by AT&T troff or ISO Latin-1. groff supports a baker's > dozen. They are in a table titled "Accents" in groff_char(7) (1.22.4). > >> diff --git a/man8/zic.8 b/man8/zic.8 >> index 940d6e814..aeca0e726 100644 >> --- a/man8/zic.8 >> +++ b/man8/zic.8 >> @@ -293,7 +293,7 @@ nor >> .q + . >> To allow for future extensions, >> an unquoted name should not contain characters from the set >> -.q !$%&'()*,/:;<=>?@[\e]^`{|}\(ti . >> +.q !$%&'()*,/:;<=>?@[\e]^\`{|}\(ti . > > You didn't proffer any complaints about the foregoing, so I assume it > was just for context (to include the whole commit, maybe). Yep > Nevertheless I think it can be further improved. > > That neutral apostrophe and caret/circumflex should be changed as well, > to ensure that they don't render as a directional closing (right) single > quote, ’ U+2019 and modifier letter circumflex ˆ U+02C6. This advice is > also in groff 1.22.4's groff_man(7) page. > > +.q !$%&\(aq()*,/:;<=>?@[\e]\(ha\`{|}\(ti . > > Moreover, as partly noted in our discussion about double quotes in macro > arguments, there were no special characters for the double quote or > neutral apostrophe in Unix troff. Since we're not getting 50 years of > backward compatibility anyway, for the Linux man-pages project I > recommend going ahead and using groff-style escape sequences for these. > > +.q !$%&\[aq]()*,/:;<=>?@[\[rs]]\[ha]\`{|}\[ti] . > > Are you willing to settle for 30 years of backward compatibility? ;-) I do :) However, I'm not going to fix this page, according to MAINTAINER_NOTES: $ cat MAINTAINER_NOTES Externally generated pages ========================== A few pages come from external sources. Fixes to the pages should really go to the upstream source. tzfile(5), zdump(8), and zic(8) come from the tz project (https://www.iana.org/time-zones) bpf-helpers(7) is autogenerated from the kernel sources using scripts. See man-pages commit 53666f6c30451cde022f65d35a8d448f5a7132ba for details. So now I wonder why this commit was written in the first place, since it breaks one page, and fixes another that shouldn't be fixed. I CCd the tz mailing list in case they want to fix the upstream page (which I couldn't find, BTW). > > In my opinion it is more helpful in dense contexts like this to have the > paired delimiters [ ] to demarcate the glyph identifier then to achieve > portability to systems that don't support identifiers you need anyway. Yes, I agree with that. > > (I note that `q` is a page-local macro and therefore bad style for > portability reasons. That said, I have been _sorely_ tempted to add a > `Q` macro for this precise purpose to groff man(7). I have hopes that > it would give people something to reach for besides bold and italics for > every damn thing.) > > Most--I hope all--of the above is discussed comprehensively in the > current version of groff_char(7)[2], which I have rewritten completely > since groff 1.22.4 and substantially modified even since the last Linux > man-pages snapshot at > <https://man7.org/linux/man-pages/man7/groff_char.7.html>. I now know > the answers to many questions of the form "why the **** is {groff,troff} > this way?", and have endeavored to share them. The "History" section is > completely new. > > Regards, > Branden > > [1] groff's own man pages are not without sin in this regard. I have > cleaned them up a lot since 1.22.4, but a few adventurous stragglers > remain that define and use page-local macros pervasively. All are > on the long side. > > [2] https://git.savannah.gnu.org/cgit/groff.git/tree/man/groff_char.7.man > > I recommend that for source perusal only; do not try to render it > with man-db man(1) or groff 1.22.4, because groff 1.23.0 will be > adding a new macro, `MR`, for man page cross references[3] and its > own pages have already been ported to use it. (This is where I > flagellate myself for not having a groff 1.23.0-rc2 out yet. :( ) > > [3] https://git.savannah.gnu.org/cgit/groff.git/tree/NEWS#n165 I like your references usually containing other references themselves. It's funny :-) Cheers, Alex -- Alejandro Colomar Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/ http://www.alejandro-colomar.es/

1 0

Re: [tz] Change Request: Europe/Kiev to Europe/Kyiv
by John Hawkinson March 18, 2022

March 18, 2022

I do not think we have handled this well; we have not given Victor Perov a good answer. Indeed, to some extent we've made it a "runaround." We can do better. We should take the time to write up a good lengthy explanation of the issues ("boilerplate"), because this a really important issue of concern to many people in the world and the project has indeed thought about it pretty carefully. Dismissing the inquiries because they are repetitive makes it seem like we haven't, and that unnecessarily upsets peopl. Victor Perev: I don't have time for a full write-up right now, but please consult the archives of the tz list (http://mm.icann.org/pipermail/tz/ or perhaps https://www.google.com/search?q=site%3Amm.icann.org%2Fpipermail%2Ftz%2F+kyiv which returns 203 results). The tz project is very conservative in its judgment for when the predominant English spelling of a city has changed, and so far the project has judged that Kiev is still preferred. We discussed it when major English newspapers and style guides changed from Kiev to Kyiv last year (prompted by the US presidential impeachment, which lead to a lot of discussion about Kyiv in America), and we will probably continue to discuss it as time goes on. But we've thought about it and discussed it a lot. The answers you got don't explain that, and that means we have not done a good a job as we should have. Sorry about that. In particular, I think Brian Inglis's answer was actually incorrect in a way that really matters ("Kiev is the correct English spelling"). There are multiple correct English spellings. It used to be that Kiev was the only one, but Kyiv is gaining popularity more and more. Paul Eggert <eggert(a)cs.ucla.edu> wrote on Sat, 15 Aug 2020 at 18:19:08 EDT in <cefc7f01-a3e9-f2a4-9ab9-5288147f994a(a)cs.ucla.edu>: > Thanks for bringing that to the mailing list (if I could shut off GitHub > pull requests I would). Although you cannot do so, we can handle them a little bit better. Please see https://docs.github.com/en/github/building-a-strong-community/creating-a-pu… You can create a template that explains to a would-be pull request submitter than pull requests will be closed and the project uses the mailing list for development discussions. ("I understand that the tz project does not use pull requests on github, and that if I enter a pull request here, it will be closed and I will be directed to send email to tz(a)iana.org.") For the particular case of regular, recurring issues, it may be worth while to keep one of #15, #26, and #27 open and mark the others as a duplicate of it, so that it is easier for newcomers to understand that this issue has been carefully considered and is not a simple oversight. https://github.com/eggert/tz/pulls?q=kiev Also, not to pick on Brian (again), but if the project policy is not to use github pull requests, it's not great to respond to pull requests on their substance, because it bifurcates the discussion and makes it seem like we actually do use pull requests ("except when we don't"). So what seems like a helpful thing may not be. -- jhawk(a)alum.mit.edu John Hawkinson

10 13

Unfortunate time zone names in the United States
by John Levine March 18, 2022

March 18, 2022

Here's the soon to be screwed up definition of US time zones. 15 USC 261 says For the purpose of establishing the standard time of the United States, the territory of the United States shall be divided into nine zones in the manner provided in this section. Except as provided in section 260a(a) of this title, the standard time of the first zone shall be Coordinated Universal Time retarded by 4 hours; that of the second zone retarded by 5 hours; that of the third zone retarded by 6 hours; that of the fourth zone retarded by 7 hours; that of the fifth zone retarded 8 hours; that of the sixth zone retarded by 9 hours; that of the seventh zone retarded by 10 hours; that of the eighth zone retarded by 11 hours; and that of the ninth zone shall be Coordinated Universal Time advanced by 10 hours. 15 USC 263 says: The standard time of the first zone shall be known and designated as Atlantic standard time; that of the second zone shall be known and designated as eastern standard time; that of the third zone shall be known and designated as central standard time; that of the fourth zone shall be known and designated as mountain standard time; that of the fifth zone shall be known and designated as Pacific standard time; that of the sixth zone shall be known and designated as Alaska standard time; that of the seventh zone shall be known and designated as Hawaii-Aleutian standard time; that of the eighth zone shall be known and designated as Samoa standard time; and that of the ninth zone shall be known as Chamorro standard time. Section 260a currently has the daylight saving rule, advance in March, fall back in November. The bill passed by the Senate deletes 260a, and updates 261 to change each of the numbers by an hour, 4 changes to 3, 5 to 4, and so forth 11 changes to 10 and the final 10 changes to 11. But it does *not* change section 263. This means that the official US names of the time zones change, which is really stupid. Since Hawaii, Samoa, and Guam do not use daylight time, Hawaii will now be in Alaska standard time, Samoa in Hawaii-Aleutian standard time, and Guam in a time zone with no name. I hope the House will fix this if they take up the bill, but I wouldn't make any changes to my time zone files yet. With respect to Canada, history shows that their timezones follow the US so if the US make a change like this, a bill in Ottawa will change Canada to match. There are currently places where you change time when you cross the border, like between Maine and New Brunswick, but it would be too painful for Montreal and Toronto and Windsor not to match New York and Detroit, and Vancouver not to match Seattle. R's, John

8 12

permanent DST and North American time zone names
by Chris Walton March 18, 2022

March 18, 2022

Regardless of what the legislation does or does not say, this database needs to quickly adopt a strategy to deal with changes that may be necessary for all North American Time zones. The supporters and maintainers of this time zone database can take an active role in helping to define and endorse a common standard, or they can sit back and watch the politicians and the general public fumble the job. It would be helpful if there was some collaboration between Microsoft and the supporters/maintainers of this database. I think it is likely that if the US government approves the Sunshine Protection Act, that most Canadian provinces and territories will follow with similar legislation. - British Columbia and Ontario already have the necessary legislation in place. - Saskatchewan has not changed its clocks in many years. - Yukon stopped changing its clocks in 2020. - Alberta recently voted to keep the biannual change, it could be the lone holdout! I admit I have not been following the other Canadian territories and provinces closely. Also, I have no clue what Mexico, Saint Pierre & Miquelon, or any of the small island nations will decide to do. For this database I can envision four options moving forward: *Option #1*: ditch the three letter time zone strings and use only numerical offsets from UTC. This is a complete cop out that says "Let's abandon our end users and let somebody else deal with the issue". It is my least favorite option. e.g. Los Angeles, Phoenix, and Vancouver: Thu Feb 1 00:00:00 *-07* 2024 (UTC-07) Thu Aug 1 00:00:00 *-07* 2024 (UTC-07) e.g. New York and Toronto: Thu Feb 1 00:00:00 *-04* 2024 (UTC-04) Thu Aug 1 00:00:00 *-04* 2024 (UTC-04) *Option #2*: allow permanent daylight saving This could be implemented without too many complications, but it goes against the philosophy that daylight saving is an alternate time offset that is only used for part of the year. This is not my favorite option even though it is probably the least disruptive. I do not think it will make any sense 20 years from now. e.g. Los Angeles, Phoenix, Vancouver, and Whitehorse would be on permanent *Pacific Daylight Time* Thu Feb 1 00:00:00 *PDT* 2024 (UTC-07) Thu Aug 1 00:00:00 *PDT* 2024 (UTC-07) e.g. New York and Toronto would be on permanent *Eastern Daylight Time*: Thu Feb 1 00:00:00 *EDT *2024 (UTC-04) Thu Aug 1 00:00:00 *EDT* 2024 (UTC-04) *Option #3*: move most North American entries in the TZ database one zone to the east: I know we have done this in the past for places such as America/Whitehorse, but I expect if we did it for all of Canada and the US it would not align with the public's perception of reality. Also, it provides no clear path to deal with any places that are currently using *Atlantic Daylight Time (UTC-03)*. e.g. Los Angeles, Phoenix, Vancouver, and Whitehorse would be on permanent *Mountain Standard Time* Thu Feb 1 00:00:00 *MST* 2024 (UTC-07) Thu Aug 1 00:00:00 *MST* 2024 (UTC-07) e.g. New York and Toronto would be on permanent *Atlantic Standard Time*: Thu Feb 1 00:00:00 *AST* 2024 (UTC-04) Thu Aug 1 00:00:00 *AST* 2024 (UTC-04) *Option #4*: redefine AKST, PST, MST, CST, EST, AST, and NST to all be one hour closer to UTC time. This is currently my preferred option even though it may break some software and it is guaranteed to conflict with the Canadian Interpretation Act. Alaska Standard Time (AKST) is redefined to UTC-08. Pacific Standard Time (PST) is redefined to UTC-07. Mountain Standard Time (MST) is redefined to UTC-06. Central Standard Time (CST) is redefined to UTC-05. Eastern Standard Time (EST) is redefined to UTC-04. Atlantic Standard Time (AST) is redefined to UTC-03. Newfoundland Standard Time (NST) is redefined to UTC-02:30 (assuming Newfoundland abandons the biannual time change) e.g. Los Angeles, Phoenix, Vancouver, and Whitehorse would be on *Pacific Standard Time* year-round: Thu Feb 1 00:00:00 *PST* 2024 (UTC-07) Thu Aug 1 00:00:00 *PST* 2024 (UTC-07) e.g. New York and Toronto would be on *Eastern Standard Time* year-round: Thu Feb 1 00:00:00 *EST* 2024 (UTC-04) Thu Aug 1 00:00:00 *EST* 2024 (UTC-04) e.g. Alberta would have to adopt new time zone names: *Pacific Standard Time* in winter, and *Pacific Daylight Time* in summer. (Alberta recently voted to keep the biannual clock change). Thu Feb 1 00:00:00 *PST* 2024 (UTC-07) Thu Aug 1 00:00:00 *PDT* 2024 (UTC-06) e.g. Saskatchewan would have to start referring to its time zone name as *Mountain Standard Time* instead of *Central Standard Time*. (Saskatchewan has used *UTC-06* year-round for many years) Thu Feb 1 00:00:00 *MST* 2024 (UTC-06) Thu Aug 1 00:00:00 *MST* 2024 (UTC-06) e.g. Puerto Rico would have to start referring to its time zone as *Eastern Standard Time* instead of *Atlantic Standard Time*. Thu Feb 1 00:00:00 *EST* 2024 (UTC-04) Thu Aug 1 00:00:00 *EST* 2024 (UTC-04) e.g. If Atlantic Canada and Bermuda were to continue changing the clocks twice a year, they would be on *Eastern Standard Time* in winter and *Eastern Daylight Time* in summer. Thu Feb 1 00:00:00 *EST* 2024 (UTC-04) Thu Aug 1 00:00:00 *EDT* 2024 (UTC-03) e.g. If, Atlantic Canada and Bermuda were to abandon the time change, then they would both end up on *Atlantic Standard Time* year-round. Thu Feb 1 00:00:00 *AST* 2024 (UTC-03) Thu Aug 1 00:00:00 *AST* 2024 (UTC-03) Did I miss anything? -chris

13 17

Iran DST change cancelled and step to avoid DST changing in their Linux system
by S Sathish S March 18, 2022

March 18, 2022

Hi Team, Customer running with Asia/Tehran (+0330, +0330) timezone, where Daylight saying is cancelled by their Iran government recently. Our Operator are requesting to avoid DST changing in their Linux system and expect tzdata patch from IANA (or) if possible any workaround to avoid this DST change in their systems. Thanks and Regards, S Sathish S

3 4

tzData Update for Iran DST
by Jahar Tyagi March 17, 2022

March 17, 2022

Hi, Recently learned that Iran has decided to stop DST changes that was about to be applied on 22nd March 2022. 2022a tzData is already released on 15th March 2022 and Iran (Asia/Tehran) DST changes are not part of this release. I want to ask what is the plan to include (Asia/Tehran) changes in tzData? Regards, Jahar Tyagi

2 2

Daylight saving in Iran changed
by Shahab Ouraie March 17, 2022

March 17, 2022

Hello. As new rule approved by government, the daylight saving time in Iran/Tehran (which was +4:30) will no longer be applied and the whole year time will be +3:30 Please consider updating this which will take effect in 4 days from now (2022 March 21st).

1 0