- tz - lists.iana.org

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

Wouldn't it be simpler if…
by Torsten Louland March 15, 2022

March 15, 2022

https://xkcd.com/1061/

2 1

Daylight Saving: Iran
by MohamadReza Farhadi March 15, 2022

March 15, 2022

Greetings, Today Iranian Parliament approved the cancelation of the Daylight Saving Time practice. The link for the article can be found here: https://www.bbc.com/persian/iran-60734716 Kindest Regards, MohamadReza Farhadi

1 0

Hong Kong listed as UK not China
by Shelley Finerty March 15, 2022

March 15, 2022

Hi there, I was using a tool that allows me to look at people’s birthdate, time and location and noticed that you still have Hong Kong listed as part of the UK with throws off the timezone for their birthdate. I had to choose another city close to Hong Kong to use it correctly. Is this something that can be changed or updated? Or are you keeping it for historical purposes? Is there a way to do both? Thanks for keeping the time so accurately - I appreciate the work you’re doing. Shelley Finerty Canada

3 2

2022a timeline?
by Deborah Goldsmith March 15, 2022

March 15, 2022

Hi, Is there an ETA for the release of (I assume) 2022a with the change for Palestine? Thank you, Deborah Goldsmith

2 1

[PATCH] URL housekeeping
by Paul Eggert March 12, 2022

March 12, 2022

* tz-link.html: Omit no-longer-active projects, and update URLs. Mention "pytz: The Fastest Footgun in the West". --- tz-link.html | 33 ++++++++++++--------------------- 1 file changed, 12 insertions(+), 21 deletions(-) diff --git a/tz-link.html b/tz-link.html index 48724ad..92da48f 100644 --- a/tz-link.html +++ b/tz-link.html @@ -89,7 +89,6 @@ title="Berkeley Software Distribution">BSD</abbr></a>, title="Web Operating System">webOS</abbr></a>, <a href="https://en.wikipedia.org/wiki/IBM_AIX"><abbr title="Advanced Interactive eXecutive">AIX</abbr></a>, -<a href="https://en.wikipedia.org/wiki/BlackBerry_10">BlackBerry 10</a>, <a href="https://www.apple.com/ios"><abbr title="iPhone OS">iOS</abbr></a>, <a href="https://www.apple.com/macos">macOS</a>, @@ -243,18 +242,18 @@ the process by tailoring the generic instructions in the <code><abbr>tz</abbr> README</code> file and installing the latest data yourself. System-specific instructions for installing the latest <code><abbr>tz</abbr></code> data have also been published -for <a href="https://www.ibm.com/developerworks/aix/library/au-aix-olson-time-zone/index…"><abbr>AIX</abbr></a>, +for <a href="https://developer.ibm.com/articles/au-aix-olson-time-zone/"><abbr>AIX</abbr></a>, <a href="https://source.android.com/devices/tech/config/timezone-rules">Android</a>, <a -href="http://userguide.icu-project.org/datetime/timezone"><abbr +href="https://unicode-org.github.io/icu/userguide/datetime/timezone/"><abbr title="International Components for Unicode">ICU</abbr></a>, -<a href="https://developer.ibm.com/javasdk/support/dst/jtzu/"><abbr>IBM</abbr> +<a href="https://www.ibm.com/support/pages/java-sdk-time-zone-update-utility"><abbr>IBM</abbr> JDK</a>, <a href="https://www.joda.org/joda-time/tz_update.html">Joda-Time</a>, <a href="https://dev.mysql.com/doc/refman/en/time-zone-support.html">MySQL</a>, <a href="https://nodatime.org/userguide/tzdb">Noda Time</a>, and <a -href="https://www.oracle.com/java/technologies/javase/tzupdater-readme.html#usage">OpenJDK/Oracle JDK</a>. +href="https://www.oracle.com/java/technologies/javase/tzupdater-readme.html">OpenJDK/Oracle JDK</a>. </p> <p>Sources for the <code><abbr>tz</abbr></code> database are <a href="https://en.wikipedia.org/wiki/UTF-8"><abbr @@ -488,11 +487,6 @@ many of which also support runtimes lacking the <samp>timeZone</samp> option. href="https://github.com/formatjs/date-time-format-timezone"><samp>Intl.DateTimeFormat</samp> timezone polyfill</a> is freely available under a <abbr>BSD</abbr>-style license.</li> -<li><a -href="https://github.com/kshetline/compact-time-zone-generator">CompactTimeZoneGenerator</a> -compiles time zone data into a compact form designed for -JavaScript. It is freely available under a combination of -the <abbr>MIT</abbr> license and the Apache License.</li> <li>The <a href="https://date-fns.org/">date-fns</a> library manipulates timezone-aware timestamps in browsers and in <a href="https://nodejs.org/en/">Node.js</a>. @@ -546,9 +540,9 @@ It is freely available under a <abbr>BSD</abbr>-style license.</li> Definitions for Python</a> compiles <code><abbr>tz</abbr></code> source into <a href="https://www.python.org">Python</a>. It is freely available under a <abbr>BSD</abbr>-style license. -In code that can assume Python 3.9 or later it is superseded by -<a href="#python-zoneinfo"><code>zoneinfo.ZoneInfo</code></a> -and the <a href="#pypi-tzdata"><code>tzdata</code> Python package</a>.</li> +In code that can assume Python 3.6 or later it is largely superseded; see <a +href="https://blog.ganssle.io/articles/2018/03/pytz-fastest-footgun.html">pytz: +The Fastest Footgun in the West</a>.</li> <li><a href="https://tzinfo.github.io">TZInfo – Ruby Timezone Library</a> compiles <code><abbr>tz</abbr></code> source into @@ -610,11 +604,11 @@ is a <abbr>TZif</abbr> file reader written in Perl. It is freely available under the same terms as Perl (dual <abbr>GPL</abbr> and Artistic license).</li> <li>Python has a <a id="python-zoneinfo" -href="https://docs.python.org/3.9/library/zoneinfo.html"><code>zoneinfo.ZoneInfo</code> +href="https://docs.python.org/3/library/zoneinfo.html"><code>zoneinfo.ZoneInfo</code> class</a> that reads <abbr>TZif</abbr> data and creates objects that represent <code><abbr>tzdb</abbr></code> timezones. Python is freely available under the -<a href="https://docs.python.org/3.9/license.html">Python Software Foundation +<a href="https://docs.python.org/3/license.html">Python Software Foundation License</a>. A companion <a id="pypi-tzdata" href="https://pypi.org/">PyPI</a> module <a href="https://pypi.org/project/tzdata/"><code>tzdata</code></a> @@ -641,7 +635,7 @@ available under a <abbr>BSD</abbr>-style license.</li> <li><a href="https://foxclocks.org">FoxClocks</a> is an extension for <a href="https://www.google.com/chrome/">Google Chrome</a> and for <a -href="https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Toolkit_API">Mozilla +href="https://wiki.mozilla.org/Modules/Toolkit">Mozilla Toolkit</a> applications like <a href="https://www.mozilla.org/en-US/firefox/new/">Firefox</a> and <a href="https://www.mozilla.org/en-US/thunderbird/">Thunderbird</a>. @@ -1010,14 +1004,11 @@ specifies a <a href="https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol"><abbr>DHCP</abbr></a> option for a server to configure a client's time zone and daylight saving settings automatically.</li> -<li><a -href="https://www.cv.nrao.edu/~rfisher/Ephemerides/times.html">Astronomical -Times</a> explains more abstruse astronomical time scales like +<li><a href="https://www.ucolick.org/~sla/leapsecs/timescales.html">Time +Scales</a> describes astronomical time scales like <abbr title="Terrestrial Dynamic Time">TDT</abbr>, <abbr title="Geocentric Coordinate Time">TCG</abbr>, and <abbr title="Barycentric Dynamic Time">TDB</abbr>. -<a href="https://www.ucolick.org/~sla/leapsecs/timescales.html">Time -Scales</a> goes into more detail, particularly for historical variants.</li> <li>The <a href="https://www.iau.org"><abbr title="International Astronomical Union">IAU</abbr></a>'s <a href="http://www.iausofa.org"><abbr -- 2.32.0

1 0

Just :)
by Sergiusz Wolicki March 11, 2022

March 11, 2022

Ryan Reynolds (@VancityReynolds) wysłał/a Tweeta o godz. 3:29 PM on pt., mar 11, 2022: As if making #TheAdamProject hadn’t satisfied enough of my childhood dreams, this happened. (I still loathe Daylight Savings.) https://t.co/9lAjYzjOnW ( https://twitter.com/VancityReynolds/status/1502290590242910208?t=zCwO45RshV… )

1 0

Re: [tz] Summer time
by heba.hamad＠mtit.gov.ps March 10, 2022

March 10, 2022

Dear sir, regarding to summer time for this year , the timing will be on 3/27/2022, but this does not necessarily mean that the change for the coming years will be on the same date. You will be provided with any new decisions about summer and winter times for the coming years and we will try to provide you with any changes more earlier than previous years. BR, في الخميس, مارس 10, 2022 14:26 EST, Paul Eggert <eggert(a)cs.ucla.edu> كتب: 3/04:50,http://www.palestinecabinet.gps/portal/Meeting/Details/51955 heba.hamad(a)mtit.gov.ps wrote: > We would like to inform you that the summer time will begin in Palestine from Sunday 03-27-2022 ,00:00 AM by 60 minutes forward. Thanks, do you have a URL for that announcement? It sounds like Palestine is changing its spring-forward rules, so that Palestine will now spring forward at 00:00 on the first Sunday on or after March 25, whereas during 2020 and 2021 Palestine sprang forward at 00:00 on the first Saturday after March 24. Is my understanding correct? Knowing the transition rule would be helpful, because TZDB makes predictions about future years, some computer applications rely on this (perhaps unwisely, but that's what they do), and the more accurate the predictions the better off everybody will be. This is related to Clive Feather's point that we need plenty of advance notice of rule changes (we'd like a year's notice). Without knowing the answers to the above questions, I installed the attached proposed patch into the TZDB development version. If possible, I'd like to improve this (based on answers to the above questions) before the next TZDB release, which should happen soon.

1 0

Summer time
by heba.hamad＠mtit.gov.ps March 10, 2022

March 10, 2022

Dear Sir, Greeting from Ministry of telecom and information technology, Palestine We would like to inform you that the summer time will begin in Palestine from Sunday 03-27-2022 ,00:00 AM by 60 minutes forward. Kindly find the attachment below that includes the decision of the Palestinian cabinet. BR

3 2

Jordan summer time zone is not updated in IANA database
by Abugharbieh, Raghad March 2, 2022

March 2, 2022

Hello I’m sure if you’re already aware of this or not , but in Jordan the timezone was changed on Thursday to meet summer changes. So currently , time zone in IANA database is behind the real time in Jordan by 1 hour . this is causing some time issues in websites that use IANA database. I’m sending this to check if there’s anything I can do to update the timezone for Jordan in the database to fix the root cause instead of handling the issues we have in a hacky way . Best regards , Raghad Abugharbieh

2 1

DST in mainstream media
by Arthur David Olson Feb. 28, 2022

Feb. 28, 2022

"Freezing the clock: Nationwide push for permanent daylight saving time gains momentum" Washington Post, 2022-02-28 (timeanddate.com gets a shoutout.) https://www.washingtonpost.com/dc-md-va/2022/02/28/permanent-daylight-savin… @dashdashado

1 0

backzone Africa/Lubumbashi
by Alois Treindl Feb. 28, 2022

Feb. 28, 2022

In file backzone there is an entry for Africa/Lubumbashi # Democratic Republic of the Congo (east) Zone Africa/Lubumbashi 1:49:52 - LMT 1897 Nov 9 2:00 - CAT There are scarce sources for time zones of former Belgian Congo. My main source for its time zone history is Henri le Corre, Régimes horaires pour l'Europe et l'Afrique. He has for the eastern provinces of Zaire GMT + 1 between 1897 Nov 9 GMT + 2 since 1920 Apr 25. Shanks follows le Corre. As does Francoise Schneider Gauquelin in he book Problèmes de l'heure resolus pout le monde entier. I think this is sufficient reason to change the zone into Zone Africa/Lubumbashi 1:49:52 - LMT 1897 Nov 9 1:00 - WAT 1920 Apr 25 2:00 - CAT For the province of Kisangani, formerly Stanleyville, le Corre gives a transition from GMT +1 to GMT + 2 on 1935 Jun 14. But as this agrees with Lubumbashi after 1970, I do not expect the creation of another backzone entry for that. This task will be left for my private pre-1970 TZ extensions.

2 1

(no subject)
by Dennis Dau Feb. 24, 2022

Feb. 24, 2022

Take Russia off the time zones for now sanctioned by the United States of America for starting war yesterday with our alias

1 0

Brisbane's lord mayor calls for referendum on Queensland DST
by Gilmore Davidson Feb. 22, 2022

Feb. 22, 2022

https://www.theguardian.com/australia-news/2022/feb/22/queensland-daylight-… Thirty years after Queenslanders rejected daylight saving at the polls, > Brisbane lord mayor, Adrian Schrinner, is calling for a new referendum on > the divisive subject. > > [...] Queenslanders voted against permanently introducing daylight saving > time after a three-year trial back in 1992. Schrinner says most people > under the age of 48 and anyone who moved to the state in the last 30 years > hasn’t had a say on adjusting time zones. > > [...] Schrinner suggested a new referendum could be held at the same time > as the next state election in 2024. > > [...] The attorney general, Shannon Fentiman, responded to an > anti-daylight saving time petition to parliament in December, saying [it] > was “not currently” under consideration. > Cheers, Gil

1 0

(no subject)
by 이상준 Feb. 22, 2022

Feb. 22, 2022

-- 이상준1978.06.28

1 0

proposed change to Europe/Kaliningrad in 1945
by Alois Treindl Feb. 21, 2022

Feb. 21, 2022

Currently the zone Europe/Kaliningrad has Zone Europe/Kaliningrad 1:22:00 - LMT 1893 Apr 1:00 C-Eur CE%sT 1945 Apr 10 2:00 Poland EE%sT 1946 Apr 7 3:00 Russia MSK/MSD 1989 Mar 26 2:00s 2:00 Russia EE%sT 2011 Mar 27 2:00s 3:00 - +03 2014 Oct 26 2:00s 2:00 - EET I wonder on which source this line is based: 2:00 Poland EE%sT 1946 Apr 7 It implies these time changes: 29 April 1945 from 2:00 to 3:00 like Poland DST 1 November 1945 from 3:00 back to 2:00 Russia took control of Königsberg/Kaliningrad in East Prussia on 10 April 1045. As a general rule, Russia imposed timezone 2:00 on occupied German territory in 1945, which is the same as German DST already in force from 2 April 1945. On 24 May 1945 Russia imposed double DST, making the effective time 3:00 east, until 24 Sept 1945, when it went back to 2:00 and then back to 1:00 (CET) on 18 Nov 1945. Now what happened in Königsberg? The Potsdam agreement of 2 August 1945 : (quote from Wikipedia) > The Conference has agreed in principle to the proposal of the Soviet > Government concerning the ultimate transfer to the Soviet Union of the > City of Koenigsberg and the area adjacent to it as described above > subject to expert examination of the actual frontier. Russia annexed the area on 17 October 1945, and integrated into the republic of Russia on 7 April 1946. Poland had no role to play in this matter. Regarding time regime, I would assume that the transition from 2:00 to 1:00 of 18 Nov 1945, for occupied Germany, did not happen in Kaliningrad. It was already annexed. It remained at 2:00 until 7 April 1946, when it was integrated and went to Moscow time. This transition on 7 April 1946 is also found in Shanks. Shanks does not have the double DST from 24 May to 24 September 1945, but I think he is wrong there. Why should the Russians have treated East Prussia from the rest of the occupied German territory in May 1945. That would make the zone table like this ( I marked the difference in red) Zone Europe/Russia/Kaliningrad 1:22:00 - LMT 1893 Apr 1:00 C-Eur CE%sT 1945 Apr 10 1:00 1:00 CEST 1945 May 24 2:00 1:00 2:00 CEMT 1945 Sep 24 3:00 1:00 1:00 CEST 1945 Oct 17 2:00 - EET 1946 Apr 7 3:00 Russia MSK/MSD 1989 Mar 26 2:00s 2:00 Russia EE%sT 2011 Mar 27 2:00s 3:00 - +03 2014 Oct 26 2:00s 2:00 - EET I have tried to simplify Zone Europe/Russia/Kaliningrad 1:22:00 - LMT 1893 Apr 1:00 C-Eur CE%sT 1945 Apr 10 1:00 SovietZone CE%sT 1945 Oct 17 2:00 - EET 1946 Apr 7 3:00 Russia MSK/MSD 1989 Mar 26 2:00s 2:00 Russia EE%sT 2011 Mar 27 2:00s 3:00 - +03 2014 Oct 26 2:00s 2:00 - EET but get an error: can't determine time zone abbreviation to use just after until time at this line in tzdata.zi 1 So CE%sT 1945 O 17 This is why I made the changes implied by rule SovietZone explicit

2 2

Maryland permanent DST
by Arthur David Olson Feb. 21, 2022

Feb. 21, 2022

A permanent-DST bill has been approved by the Maryland House of Delegates on a third-and-final 108-24 vote; it now goes to the state senate. Text of the bill is available at... https://mgaleg.maryland.gov/2022RS/bills/hb/hb0126T.pdf …and status of the bill at... https://mgaleg.maryland.gov/mgawebsite/Legislation/Details/hb0126 There are contigencies: (1) enacting of a similar act by Delaware, the District of Columbia, Pennsylvania, Virginia, and West Virginia; and (2) 15 U.S.C. § 260a being amended to allow the states or a state, individually, to observe a year–round standard time that is consistent with Eastern Daylight Time Alas, if the contingencies are met there may be short lead time before a change: Section 1 of this Act shall take effect on the earlier of the second Sunday of March or the first Sunday of November after the [contigencies have been met]… Alas further, the senate (unlike the house) has returned to in-person hearings; written communications can be sent. One suggestion I’ve thought of making is to change “the earlier of” to “the later of” for kick-in; that would buy at least a few guaranteed months of lead time. I’d welcome any better suggestions; I’d also welcome any Marylander with more political weight than I have (read: anyone) to weigh in. --ado

6 6

Issues about parts of Europe/Moscow in 1981/1982
by Alois Treindl Feb. 21, 2022

Feb. 21, 2022

I have the impression that some of the comments in the Russia section in file 'europe' have not been followed through in the actual zone tables. I refer to the lines beginning here # From Stepan Golosunov (2016-03-07): # 11. Regions-violators, 1981-1982. # Wikipedia refers to # http://maps.monetonos.ru/maps/raznoe/Old_Maps/Old_Maps/Articles/022/3_1981.… # http://besp.narod.ru/nauka_1981_3.htm ... until # 12. Udmurtia Also the Russian wikipedia page https://ru.wikipedia.org/wiki/%D0%9C%D0%BE%D1%81%D0%BA%D0%BE%D0%B2%D1%81%D0… contains the sentence (in Google translation) > In the autumn of 1981, Arkhangelsk, Vologda, Yaroslavl, Ivanovo, > Vladimir, Ryazan, Lipetsk, Voronezh, Rostov-on-Don, Krasnodar and > regions to the east of those named (about 30 in total) parted ways > with Moscow time.However, the convenience of common time with Moscow > turned out to be decisive - in 1982, these regions again switched to > Moscow time. Shanks International atlas has similar information, and also the Russian book Zaitsev A., Kutalev D. A new astrologer's reference book. Coordinates of cities and time corrections, - The World of Urania, 2012 Russian: Зайцев А., Куталёв Д., Новый справочник астролога. Координаты городов и временные поправки To me it seems that an extra zone is needed, which starts with LMT util 1919, later follows Moscow since 1930, but deviates from it between 1 October 1981 until 1 April 1982. I suggest to call this zone Europe/Yaroslavl, because Yaroslavl with a population of 608'000 seems to be largest city in the deviating area.

3 4