- tz - lists.iana.org

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

[tz-announce] 2022a release of tz code and data available
by Paul Eggert via tz-announce March 17, 2022

March 17, 2022

The 2022a release of the tz code and data is available. This release reflects the following changes: Briefly: Palestine will spring forward on 2022-03-27, not -03-26. zdump -v now outputs better failure indications. Bug fixes for code that reads corrupted TZif data. Changes to future timestamps Palestine will spring forward on 2022-03-27, not 2022-03-26. (Thanks to Heba Hamad.) Predict future transitions for first Sunday >= March 25. Additionally, predict fallbacks to be the first Friday on or after October 23, not October's last Friday, to be more consistent with recent practice. The first differing fallback prediction is on 2025-10-24, not 2025-10-31. Changes to past timestamps From 1992 through spring 1996, Ukraine's DST transitions were at 02:00 standard time, not at 01:00 UTC. (Thanks to Alois Treindl.) Chile's Santiago Mean Time and its LMT precursor have been adjusted eastward by 1 second to align with past and present law. Changes to commentary Add several references for Chile's 1946/1947 transitions, some of which only affected portions of the country. Changes to code Fix bug when mktime gets confused by truncated TZif files with unspecified local time. (Problem reported by Almaz Mingaleev.) Fix bug when 32-bit time_t code reads malformed 64-bit TZif data. (Problem reported by Christos Zoulas.) When reading a version 2 or later TZif file, the TZif reader now validates the version 1 header and data block only enough to skip over them, as recommended by RFC 8536 section 4. Also, the TZif reader no longer mistakenly attempts to parse a version 1 TZIf file header as a TZ string. zdump -v now outputs "(localtime failed)" and "(gmtime failed)" when local time and UT cannot be determined for a timestamp. Changes to build procedure Distribution tarballs now use standard POSIX.1-1988 ustar format instead of GNU format. Although the formats are almost identical for these tarballs, ustar headers' magic fields contain "ustar" instead of "ustar ", and their version fields contain "00" instead of " ". The two formats are planned to diverge more significantly for tzdb releases after 2242-03-16 12:56:31 UTC, when the ustar format becomes obsolete and the tarballs switch to pax format, an extension of ustar. For details about these formats, please see "pax - portable archive interchange", IEEE Std 1003.1-2017, <https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_…>. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2022a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2022a.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2022a.tar.lz The following convenience links are also available, although they may point to the previous release until the relevant caches are refreshed: https://www.iana.org/time-zones/repository/tzcode-latest.tar.gz https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz https://www.iana.org/time-zones/repository/tzdb-latest.tar.lz Links are also available via plain HTTP, and via FTP from ftp://ftp.iana.org/tz/releases with the same basenames as above. Each release file has a GPG signature, which can be retrieved by appending ".asc" to the above URLs. Copies of these signatures are appended to this message. This release corresponds to commit 95ecc37d29c2f5cf711af43b0ef3a35fc2847aa1 dated 2022-03-15 23:02:01 -0700 and tagged '2022a' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 3f047a6f414ae3df4a3d6bb9b39a1790833d191ae48e6320ab9438cd326dc455475186a02c44e4cde96b48101ab000880919b1e0e8092aed7254443ed2c831ed tzcode2022a.tar.gz 542e4559beac8fd8c4af7d08d816fd12cfe7ffcb6f20bba4ff1c20eba717749ef96e5cf599b2fe03b5b8469c0467f8cb1c893008160da281055a123dd9e810d9 tzdata2022a.tar.gz ece0b7a9ad3d365f8605e8f98a8a78b7fdbbb8aa615b585f21256d9401c59845fcdc951f5fc876293f1b7956b1a2d3fa2baf85099d637a91d4199ee30cf4307e tzdb-2022a.tar.lz Here are the GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmIxfhAACgkQ7ZfpDmKq fjRXfw/8DC6daRCaFirmN6821H+CA0D/e0Iod9e2g/Z5/yyx5HGCEAfRBhJ6ThWA O1I8oCuwp2kaP2ZH87+HKXT1WXGMx/819FU5fqY2TNncHAUxVUSmAm1yVHWaY2nU qFt3gDTx4vDV0lfSDtKYJJdVeE+VcAdSDUDnYIqMNCKuTkKdTfPVparsAPIZ8egr EC4IBiGolLoLkMiiwvvPNg0J505I+DUYeHEuo+ezhgBzBiLNhCWDfCcghoDYakHr CEH+aq6BVhhn/3w1203ExN7iEr/5iTwC/PjRZoJlBqDS7eAhycgFYHjglHGYSs8P RVNnkTAhDMxONZH97QqKlOo56a5QLMvTDNbBLdX0b4K4lmEfCRe03MbH4ybDkA9S +eYfkeX2kUYKnHTT3XXTiVvjDFGemu+l8QGlJoF9Qu44cUGLPZQZEq/YzbZUw8ax RaT4V0ZkH3+yMYAAWaoa85xXs7a/MnE7Gl9glSFzlijC6iZoRmrXy2ra44TzvwWr E/7Het1lctaiKWcdYH5+vYyzzWZTt4hKAXsCUgBGQy0/mE2KoHRQHk6zfZPY1TvD ib6Dkh9LWYrXsNGCe1H4SpjKEX51Nb27FgIw1DNrbOJpTna5/OKmceu5IIlGJseF nfwPHZ3ATpVfVwdiRqbNC9GNVBev9n5UI67zGQ2494kknR2JMhs= =4JUm -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmIxfhAACgkQ7ZfpDmKq fjTlWw/7BrBTwRx7HvTlNaIbCaj/uOIEomJafNOq8Kdbx2JXrZu8qhj/0vMdwIzQ CEIqVuGKD8WJB4nsBYlFU8Jn1JfRbglnWK1f7yRY1EaXuIFh+FMbRYEk8O3HYPy2 14QCJNjsCwIzztmiuxXqET2eQRpT2iojGKhZbToJE4DpC/w5xCPrUqAIsK8nfC3u TZC8l09zL/xTSl/QMStH/Kh8oJD4uftVMxYZE5zakZaH5M017gwjDdM/7I/D4MME sTm7XEL7IdzzZyTxzeVVbXfyqoEb1ueJJImYnQfGgCnoJKtMjVROzL6BBJSZLkZN tR7/V9mHZKoItzhOv5gwfk0YMy8792rAioqfMUG/KvrvCTNy3PqrE1jO1/nv+FPS WWuixsnRx1Xz2COb88pKnYX17Zt8rBIumcfpgolsBvLKGI7ZLEAekjteKubgpebn jnf6CLAdcRoIdauG483LG/OQ6M9PEUBYTrX56Q8/C3kdOPuuMJ/6qd6k7lNt/fWx O2lBg+lkIagZu8j5pU5mHOsVe2P1f7p7oIt1NF2oAD2cIq6EFWOdcOCyvgC69xE1 +jt6lIQkIfBM8dfxf70z9KZQvOr9bwZaCirWNTgIMxrn/n4vvo5HCbYx+P4LSAhH G1UY/x67Swnl0p6+69d8Ww/SrdOP3T30KxjIaQXx5NgjeU2zIEo= =OX/x -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmIxfhEACgkQ7ZfpDmKq fjTWBQ//T8ICtN33H3kcz/4P9gWArfgV7huztvWW9KKBkQpWEa9gIlpYi7jx80wF qnAHZCpRedj+CJXqswkG+lIMVLEHjwVT2hdeP5wPV2y5rJ0J9Ssh2i0voSdX000T WED4u/OyR1shKm4VIxdgY6eqaN6Hedc0+Eib/VoIQAzCM2nP3c4IMAWkBKLiCSIZ n6JVI90jRgAnzhRJjiddJRFMBovzKNIxpqGGZYaxaG0O5AYfsItdRte3RCOn/tc+ tsMSJ+iUt8nTonq4P1nUE4zmvx33V7iOJhaj03fdJal0U8Egc/Ib5exsS2KipEjG iknyi8dUQcbNBFnFoN26SAO9/QMpDDE/vOnGGyWySLSwQg/xmy+LwmIZGqVftDeX JrUeRboH/39aDx6kKIrqXeIlG9bNka/6ThOJEZNr+OejDRyFeqgcatpomRkoExRs pPR88cyA0ZsN3PHhi9eXO+Zyk9GBA0o7m7G0ECK2j6w2axPh8/xPQ94zdFRTcd3V 3xC94N42eoNKeWgEmyvNEXdq5hZXhPK/Lu8D0NScbS440ovMJJtcr8Q+/bihHyGG eOCrxVF5KXLOYvptQ/xhUGodzRm8PuZ6DkJoCtW9PQL82LZDSHAi880YgzsdWzzy 6m6g8KmOmTkmQ6vztMyDr04KW2QDxp53q7hdErh0bW0iyvELd7I= =egWc -----END PGP SIGNATURE----- PS. If your tzdata parser does not yet support negative DST offsets or times past 24:00, or if it insists on a 'pacificnew' file that is no longer present, this release's data entries can be turned into a rearguard-format tarball that should work even with these older parsers. This is intended to be a temporary transition aid for these parsers. To generate a rearguard-format tarball, obtain the full distribution as described above, and run the command 'make rearguard_tarballs' on a development host. Or you can run 'make rearguard.zi' to generate a single file that can be fed directly to a parser that works like 'zic'.

1 0

Permanent DST in the United States
by Jacob Pratt March 16, 2022

March 16, 2022

The "Sunshine Protection Act" has passed the US Senate with unanimous consent. It now moves on to the House. My reading of the text is that this would mandate permanent DST for the 48 states that currently observe it, with Arizona (sans the Navajo Nation) and Hawaii able to choose. Notably there is no clause that delays implementation, so it looks like it would take effect immediately. This could be problematic if the bill becomes law near or after the November clock change. https://www.congress.gov/bill/117th-congress/senate-bill/623/text Jacob Pratt

4 5

gmtime failed messages for zdump on Windows with latest git code
by Manuela Friedrich March 16, 2022

March 16, 2022

Hello Paul, I noticed that zdump on Windows from the latest git code now produces "localtime failed" and "gmtime failed" messages. Is that expected? Does it also happen on Linux? New behaviour with git code: zdump.exe -v d:\devsrc\treasure_test\iana\zoneinfo\iana\Africa\Abidjan d:\zoneinfo\iana\Africa\Abidjan -9223372036854775808 (gmtime failed) = -9223372036854775808 (localtime failed) d:\zoneinfo\iana\Africa\Abidjan -67768040609740801 (gmtime failed) = -67768040609740801 (localtime failed) d:\zoneinfo\iana\Africa\Abidjan Thu Jan 1 00:00:00 -2147481748 UT = -67768040609740800 (localtime failed) d:\zoneinfo\iana\Africa\Abidjan Thu Jan 1 00:16:07 -2147481748 UT = -67768040609739833 (localtime failed) d:\zoneinfo\iana\Africa\Abidjan Thu Jan 1 00:16:08 -2147481748 UT = Thu Jan 1 00:00:00 -2147481748 LMT isdst=0 gmtoff=-968 d:\zoneinfo\iana\Africa\Abidjan Mon Jan 1 00:16:07 1912 UT = Sun Dec 31 23:59:59 1911 LMT isdst=0 gmtoff=-968 d:\zoneinfo\iana\Africa\Abidjan Mon Jan 1 00:16:08 1912 UT = Mon Jan 1 00:16:08 1912 GMT isdst=0 gmtoff=0 d:\zoneinfo\iana\Africa\Abidjan Wed Dec 31 23:59:59 2147485547 UT = Wed Dec 31 23:59:59 2147485547 GMT isdst=0 gmtoff=0 d:\zoneinfo\iana\Africa\Abidjan 67768036191676800 (gmtime failed) = 67768036191676800 (localtime failed) d:\zoneinfo\iana\Africa\Abidjan 9223372036854775807 (gmtime failed) = 9223372036854775807 (localtime failed) Output from 2021e zdump.exe -v d:\zoneinfo\iana\Africa\Abidjan d:\zoneinfo\iana\Africa\Abidjan -9223372036854775808 = NULL d:\zoneinfo\iana\Africa\Abidjan -67768040609740801 = NULL d:\zoneinfo\iana\Africa\Abidjan Thu Jan 1 00:00:00 -2147481748 UT = NULL d:\zoneinfo\iana\Africa\Abidjan Thu Jan 1 00:16:07 -2147481748 UT = NULL d:\zoneinfo\iana\Africa\Abidjan Thu Jan 1 00:16:08 -2147481748 UT = Thu Jan 1 00:00:00 -2147481748 LMT isdst=0 gmtoff=-968 d:\zoneinfo\iana\Africa\Abidjan Mon Jan 1 00:16:07 1912 UT = Sun Dec 31 23:59:59 1911 LMT isdst=0 gmtoff=-968 d:\zoneinfo\iana\Africa\Abidjan Mon Jan 1 00:16:08 1912 UT = Mon Jan 1 00:16:08 1912 GMT isdst=0 gmtoff=0 d:\zoneinfo\iana\Africa\Abidjan Wed Dec 31 23:59:59 2147485547 UT = Wed Dec 31 23:59:59 2147485547 GMT isdst=0 gmtoff=0 d:\zoneinfo\iana\Africa\Abidjan 67768036191676800 = NULL d:\zoneinfo\iana\Africa\Abidjan 9223372036854775807 = NULL Thank you! Regards Manuela Friedrich

2 2