September 2022 - tz - lists.iana.org

(no subject)
by Cool Gab19 Nov. 8, 2024

Nov. 8, 2024

can you add Philippine Daylight Time on your Database I think it was missing from the list of the time zones please reply immediately if solved thanks...

4 8

Buggy %z behaviour in strftime
by Almaz Mingaleev May 16, 2023

May 16, 2023

Attached code prints "+0000 America/Los_Angeles" both with glibc and with linked ToT strftime implementation. On MacOs it prints "-0800 America/Los_Angeles". Is it a known issue?

10 19

Re: [tz] Morocco : Ramdan Time Change 2021
by Paul Eggert March 15, 2023

March 15, 2023

On 3/19/21 3:15 AM, Semlali Naoufal wrote: > At the moment, we have no official government announcement to this effect. But, logically, the change to the GMT schedule should be made on the night of April 10-11, 2021 (last weekend before Ramadan). Yes, that's been the tzdb prediction too, ever since tzdb version 2018h (2018-12-23). For the record, here are tzdb's current predictions Morocco transitions during the next five years. Sun Apr 11 01:59:59 2021 UT = Sun Apr 11 02:59:59 2021 +01 Sun Apr 11 02:00:00 2021 UT = Sun Apr 11 02:00:00 2021 +00 Sun May 16 01:59:59 2021 UT = Sun May 16 01:59:59 2021 +00 Sun May 16 02:00:00 2021 UT = Sun May 16 03:00:00 2021 +01 Sun Mar 27 01:59:59 2022 UT = Sun Mar 27 02:59:59 2022 +01 Sun Mar 27 02:00:00 2022 UT = Sun Mar 27 02:00:00 2022 +00 Sun May 8 01:59:59 2022 UT = Sun May 8 01:59:59 2022 +00 Sun May 8 02:00:00 2022 UT = Sun May 8 03:00:00 2022 +01 Sun Mar 19 01:59:59 2023 UT = Sun Mar 19 02:59:59 2023 +01 Sun Mar 19 02:00:00 2023 UT = Sun Mar 19 02:00:00 2023 +00 Sun Apr 30 01:59:59 2023 UT = Sun Apr 30 01:59:59 2023 +00 Sun Apr 30 02:00:00 2023 UT = Sun Apr 30 03:00:00 2023 +01 Sun Mar 10 01:59:59 2024 UT = Sun Mar 10 02:59:59 2024 +01 Sun Mar 10 02:00:00 2024 UT = Sun Mar 10 02:00:00 2024 +00 Sun Apr 14 01:59:59 2024 UT = Sun Apr 14 01:59:59 2024 +00 Sun Apr 14 02:00:00 2024 UT = Sun Apr 14 03:00:00 2024 +01 Sun Feb 23 01:59:59 2025 UT = Sun Feb 23 02:59:59 2025 +01 Sun Feb 23 02:00:00 2025 UT = Sun Feb 23 02:00:00 2025 +00 Sun Apr 6 01:59:59 2025 UT = Sun Apr 6 01:59:59 2025 +00 Sun Apr 6 02:00:00 2025 UT = Sun Apr 6 03:00:00 2025 +01 Sun Feb 15 01:59:59 2026 UT = Sun Feb 15 02:59:59 2026 +01 Sun Feb 15 02:00:00 2026 UT = Sun Feb 15 02:00:00 2026 +00 Sun Mar 22 01:59:59 2026 UT = Sun Mar 22 01:59:59 2026 +00 Sun Mar 22 02:00:00 2026 UT = Sun Mar 22 03:00:00 2026 +01 Sun Feb 7 01:59:59 2027 UT = Sun Feb 7 02:59:59 2027 +01 Sun Feb 7 02:00:00 2027 UT = Sun Feb 7 02:00:00 2027 +00 Sun Mar 14 01:59:59 2027 UT = Sun Mar 14 01:59:59 2027 +00 Sun Mar 14 02:00:00 2027 UT = Sun Mar 14 03:00:00 2027 +01 Sun Jan 23 01:59:59 2028 UT = Sun Jan 23 02:59:59 2028 +01 Sun Jan 23 02:00:00 2028 UT = Sun Jan 23 02:00:00 2028 +00 Sun Mar 5 01:59:59 2028 UT = Sun Mar 5 01:59:59 2028 +00 Sun Mar 5 02:00:00 2028 UT = Sun Mar 5 03:00:00 2028 +01 Sun Jan 14 01:59:59 2029 UT = Sun Jan 14 02:59:59 2029 +01 Sun Jan 14 02:00:00 2029 UT = Sun Jan 14 02:00:00 2029 +00 Sun Feb 18 01:59:59 2029 UT = Sun Feb 18 01:59:59 2029 +00 Sun Feb 18 02:00:00 2029 UT = Sun Feb 18 03:00:00 2029 +01 Sun Dec 30 01:59:59 2029 UT = Sun Dec 30 02:59:59 2029 +01 Sun Dec 30 02:00:00 2029 UT = Sun Dec 30 02:00:00 2029 +00 Sun Feb 10 01:59:59 2030 UT = Sun Feb 10 01:59:59 2030 +00 Sun Feb 10 02:00:00 2030 UT = Sun Feb 10 03:00:00 2030 +01 Sun Dec 22 01:59:59 2030 UT = Sun Dec 22 02:59:59 2030 +01 Sun Dec 22 02:00:00 2030 UT = Sun Dec 22 02:00:00 2030 +00

3 9

Paraguay on its way to stay on DST
by Carlos Raúl Perasso March 2, 2023

March 2, 2023

On September 28, the Paraguayan Chamber of Deputies approved a bill that eliminates winter time in Paraguay. This would make Paraguay stay in DST throughout the year. The project was sent to the Senate for approval. After this, it could still have the presidential veto. If successful, the law would take effect after this weekend's time change, so the new rule should read as follows: Rule Para 2010 2022 - Oct Sun>=1 0:00 1:00 - Rule Para 2013 2022 - Mar Sun>=22 0:00 0 - I will keep you informed of the progress of the bill. Saludos, Carlos

2 2

United States Senate reintroduced Sunshine Protection Act, enabling Permanent DST
by Phake Nick Nov. 14, 2022

Nov. 14, 2022

I don't quite understand the legal text of the bill itself [2], but according to my reading, it seems like the bill will end DST across the entire US by shifting the standard time forward an hour, except in states/territories/area that currently doesn't enact DST, which they can choose to follow the new standard time or old standard time? 1: https://www.rubio.senate.gov/public/index.cfm/2021/3/rubio-colleagues-reint… 2: https://www.rubio.senate.gov/public/_cache/files/d34c77c0-acea-4074-bc57-14…

18 26

Mexico on track to abolish DST
by Paul Eggert Nov. 3, 2022

Nov. 3, 2022

Yesterday Mexico's Chamber of Deputies voted 445–33 to abolish DST in most of Mexico, and although there are more hurdles I expect this to become law. When that happens, I hope the following simple patch will suffice; it merely changes "max" to "2022" in the last two Mexico Rule lines. We'll also need to add commentary citing the law, etc., but you can try this patch now if you like, to debug any applications involving future time in Mexico. Today timeanddate updated their English-language summary of this <https://www.timeanddate.com/news/time/mexico-remove-dst-2022.html>. I haven't installed the following. diff --git a/northamerica b/northamerica index da84f354..2466d627 100644 --- a/northamerica +++ b/northamerica @@ -2634,2 +2634,2 @@ Rule Mexico 2001 only - Sep lastSun 2:00 0 S -Rule Mexico 2002 max - Apr Sun>=1 2:00 1:00 D -Rule Mexico 2002 max - Oct lastSun 2:00 0 S +Rule Mexico 2002 2022 - Apr Sun>=1 2:00 1:00 D +Rule Mexico 2002 2022 - Oct lastSun 2:00 0 S

4 16

Re: [tz] iana build failures on Windows
by Paul Eggert Nov. 2, 2022

Nov. 2, 2022

On 4/19/21 7:09 AM, Manuela Friedrich wrote: > I had to include signal.h in zic.c to prevent the following error: > > zic.c(610): error C2061: syntax error: identifier 'got_signal' This is a portability bug recently introduced to zic.c. I installed the first attached patch to fix it. > The I needed to resolved error > > zic.obj : error LNK2019: unresolved external symbol tz_time referenced in function random_dirent This appears to be another recent portability bug. It's related to a portability problem you reported on MS-Windows in response to which in 2018d I committed a patch that introduced RESERVE_STD_EXT_IDS: https://github.com/eggert/tz/commit/24b45243c5210b4196987fdd06e6c288c358a268 When I recently added the randomish filename code to the development version, I neglected to deal with RESERVE_STD_EXT_IDS. The second attached patch should fix this issue. Please give the two patches a try, as I don't use MS-Windows and can't easily test these patches on that platform. > a test run of zdump -v produced way more output than in the last release, the Linux output seems to have become longer too, but maybe this is still under development. That change is intentional, and was caused by this: https://github.com/eggert/tz/commit/ac07b446a3afaa4cb1ae11a91785a201c91f6351 along with some neighboring commits. Thanks for reporting the problems, and I hope the current development version of tzdb addresses the issues you mentioned.

5 23

[PATCH 0/5] Simplifying Link line maintenance
by Paul Eggert Oct. 17, 2022

Oct. 17, 2022

Although TZDB currently puts most Link lines in the ‘backward’ file, some Link lines reside in the continental files ‘africa’, ‘antarctica’, etc., with little rhyme or reason as to which lines are in ‘backward’ and which line are in a continental file. This is confusing and makes maintenance a bit more difficult. This proposed series of patches aims to regularize this by putting the Link lines into ‘backward’, except that to work around a TZUpdater bug the GMT Link line is in ‘backward’ only when using vanguard form. As part of these patches, the Link lines in ‘backward’ are organized into sections that better explain the reason for each Link line. Also, comments are added to document shortcut Link lines, that is, Link lines reworded to reference the target rather than the source of another Link line. Furthermore, the Makefile is augmented to check Link lines more carefully. The overall effect of this patch is to shrink TZDB’s source code and make maintenance simpler and more robust, without affecting data except for users who are purposely bleeding-edge by omitting all backward-compatibility links. Because these patches are nontrivial I have not installed them in the development repository, and there is no rush. Comments welcome as usual. Paul Eggert (5): Move a few links to ‘backward’ Move most remaining links to ‘backward’ Reorder 'backward’ Improve checking for shortcut links Coalesce some commentary Makefile | 6 +- NEWS | 17 +++ africa | 213 ++++++++++-------------------------- antarctica | 2 +- asia | 69 ++++-------- australasia | 46 +++----- backward | 288 +++++++++++++++++++++++++++++++++++++++---------- checklinks.awk | 17 +++ etcetera | 17 ++- europe | 202 ++++++++++++---------------------- northamerica | 86 ++++----------- southamerica | 15 --- theory.html | 1 + zdump.c | 4 +- ziguard.awk | 14 +++ 15 files changed, 472 insertions(+), 525 deletions(-) -- 2.37.3

2 8

[PROPOSED] Treat 1931 changes in Mexico as DST
by Paul Eggert Sept. 30, 2022

Sept. 30, 2022

Mexico’s Chamber of Deputies was supposed to vote today on legislation abolishing DST in most of Mexico. Although the vote was delayed due to Internet problems, news coverage of the non-event led me to review our sources for DST in Mexico, and I found that tzdb considered the transitions in 1931 to be two changes to standard time, whereas it is considered to be DST in today’s news coverage, as well as in our main source, the history of Mexican local time published by the Investigation and Analysis Service of the Mexican Library of Congress. Fix this by considering the 1931 changes to be DST, not standard time. * NEWS: Mention this. * northamerica (Mexico): Add DST rules for 1931. (America/Mexico_City, America/Ojinaga, America/Chihuahua) (America/Hermosillo, America/Mazatlan, America/Bahia_Banderas): Use them. --- NEWS | 9 +++++++++ northamerica | 26 ++++++++------------------ 2 files changed, 17 insertions(+), 18 deletions(-) diff --git a/NEWS b/NEWS index 64327d0..bcdad41 100644 --- a/NEWS +++ b/NEWS @@ -1,5 +1,14 @@ News for the tz database +Unreleased, experimental changes + + Changes to past time zone abbreviations and DST flags + + The temporary advancement of clocks in central Mexico in summer + 1931 is now treated as daylight saving time, instead of as two + changes to standard time. + + Release 2022d - 2022-09-23 12:02:57 -0700 Briefly: diff --git a/northamerica b/northamerica index 13fb064..f848228 100644 --- a/northamerica +++ b/northamerica @@ -2617,6 +2617,8 @@ Zone America/Dawson -9:17:40 - LMT 1900 Aug 20 # longitude they are located at. # Rule NAME FROM TO - IN ON AT SAVE LETTER/S +Rule Mexico 1931 only - May 1 23:00 1:00 D +Rule Mexico 1931 only - Oct 1 0:00 0 S Rule Mexico 1939 only - Feb 5 0:00 1:00 D Rule Mexico 1939 only - Jun 25 0:00 0 S Rule Mexico 1940 only - Dec 9 0:00 1:00 D @@ -2667,9 +2669,7 @@ Zone America/Monterrey -6:41:16 - LMT 1921 Dec 31 23:18:44 Zone America/Mexico_City -6:36:36 - LMT 1922 Jan 1 0:23:24 -7:00 - MST 1927 Jun 10 23:00 -6:00 - CST 1930 Nov 15 - -7:00 - MST 1931 May 1 23:00 - -6:00 - CST 1931 Oct - -7:00 - MST 1932 Apr 1 + -7:00 Mexico M%sT 1932 Apr 1 -6:00 Mexico C%sT 2001 Sep 30 2:00 -6:00 - CST 2002 Feb 20 -6:00 Mexico C%sT @@ -2680,9 +2680,7 @@ Zone America/Mexico_City -6:36:36 - LMT 1922 Jan 1 0:23:24 Zone America/Ojinaga -6:57:40 - LMT 1922 Jan 1 0:02:20 -7:00 - MST 1927 Jun 10 23:00 -6:00 - CST 1930 Nov 15 - -7:00 - MST 1931 May 1 23:00 - -6:00 - CST 1931 Oct - -7:00 - MST 1932 Apr 1 + -7:00 Mexico M%sT 1932 Apr 1 -6:00 - CST 1996 -6:00 Mexico C%sT 1998 -6:00 - CST 1998 Apr Sun>=1 3:00 @@ -2692,9 +2690,7 @@ Zone America/Ojinaga -6:57:40 - LMT 1922 Jan 1 0:02:20 Zone America/Chihuahua -7:04:20 - LMT 1921 Dec 31 23:55:40 -7:00 - MST 1927 Jun 10 23:00 -6:00 - CST 1930 Nov 15 - -7:00 - MST 1931 May 1 23:00 - -6:00 - CST 1931 Oct - -7:00 - MST 1932 Apr 1 + -7:00 Mexico M%sT 1932 Apr 1 -6:00 - CST 1996 -6:00 Mexico C%sT 1998 -6:00 - CST 1998 Apr Sun>=1 3:00 @@ -2703,9 +2699,7 @@ Zone America/Chihuahua -7:04:20 - LMT 1921 Dec 31 23:55:40 Zone America/Hermosillo -7:23:52 - LMT 1921 Dec 31 23:36:08 -7:00 - MST 1927 Jun 10 23:00 -6:00 - CST 1930 Nov 15 - -7:00 - MST 1931 May 1 23:00 - -6:00 - CST 1931 Oct - -7:00 - MST 1932 Apr 1 + -7:00 Mexico M%sT 1932 Apr 1 -6:00 - CST 1942 Apr 24 -7:00 - MST 1949 Jan 14 -8:00 - PST 1970 @@ -2743,9 +2737,7 @@ Zone America/Hermosillo -7:23:52 - LMT 1921 Dec 31 23:36:08 Zone America/Mazatlan -7:05:40 - LMT 1921 Dec 31 23:54:20 -7:00 - MST 1927 Jun 10 23:00 -6:00 - CST 1930 Nov 15 - -7:00 - MST 1931 May 1 23:00 - -6:00 - CST 1931 Oct - -7:00 - MST 1932 Apr 1 + -7:00 Mexico M%sT 1932 Apr 1 -6:00 - CST 1942 Apr 24 -7:00 - MST 1949 Jan 14 -8:00 - PST 1970 @@ -2755,9 +2747,7 @@ Zone America/Mazatlan -7:05:40 - LMT 1921 Dec 31 23:54:20 Zone America/Bahia_Banderas -7:01:00 - LMT 1921 Dec 31 23:59:00 -7:00 - MST 1927 Jun 10 23:00 -6:00 - CST 1930 Nov 15 - -7:00 - MST 1931 May 1 23:00 - -6:00 - CST 1931 Oct - -7:00 - MST 1932 Apr 1 + -7:00 Mexico M%sT 1932 Apr 1 -6:00 - CST 1942 Apr 24 -7:00 - MST 1949 Jan 14 -8:00 - PST 1970 -- 2.37.3

2 2

Moving more zones to 'backzone'
by Paul Eggert Sept. 29, 2022

Sept. 29, 2022

Release 2021b moved to 'backzone' nine zones whose timestamps since 1970 were duplicates of other zones, as part of a process that started in 2013 in the interests of removing prior inequities, one step at a time. If we were to continue this process in the same way, we could install the attached proposed patch which would move more zones, chosen via the same procedure used for 2021b. It strikes me, though, now that Stephen Colebourne has established a mechanism that can let downstream users keep the duplicate-since-1970 zones, that it may be a more effective use of our time to move the rest of the duplicate-si ce-1970 zones now, while no urgent changes are pending. This would move another twelve zones if I've counted correctly, and would let us more efficiently turn our attention to other issues. Comments welcome.

18 50

Re: [tz] Direct implementation of mktime_z
by Ted Phelps Sept. 28, 2022

Sept. 28, 2022

Hi Tony, On 2022-09-24, Tony Finch wrote: > You might also like https://dotat.at/@/2008-09-10-counting-the-days.html > (That does things the hard way, rather than relying on tm_yday) > and https://dotat.at/@/2008-09-15-the-date-of-the-count.html Wow, that's some clever math you've done there; far nicer than the clumsy approach I'd used to canonicalize the year, month and day. It's a little slower than my clumsy approach in the case where the year, month and day are already in canonical form, but can be much faster when they're not. I'll incorporate those changes into my git project in the coming days, thank you! -Ted

4 7

[news] DOT to map out nation’s time zones after report shows no official map exists
by Tony Finch Sept. 27, 2022

Sept. 27, 2022

https://edition.cnn.com/2022/09/22/politics/time-zone-map-transportation-de… : Federal transportation officials are now at work creating an accurate : map of the nation’s time zones, according to a report by the inspector : general for the Department of Transportation. : : The issue came up, the inspector general’s office said, after the US : Senate passed legislation this year to end the biannual time turn by : making Daylight Saving Time permanent. : : Investigators found no single map accurately showing the boundaries : nationwide and said several sources of time information on the DOT : website contained errors, such as inaccurately noting the time practices : in some localities. For example, one map incorrectly identifies a : deviation in Nevada: “Elko County, NV is shown as the location that : changed time zones rather than the correct location, the city of West : Wendover.” : : “The official boundaries are narratively described [in federal : regulations] with various types of coordinates and geographic features : such as lines of longitude, State or county lines, and rivers,” the : report stated. -- Tony Finch <dot(a)dotat.at> https://dotat.at/ Sole: Northwest 5 to 7, occasionally gale 8 until later. Rough or very rough. Rain or showers. Good, occasionally poor.

1 0

Direct implementation of mktime_z
by Ted Phelps Sept. 24, 2022

Sept. 24, 2022

Hi folks, I'm not sure if this is of interest here or not, but... I recently found myself needing to be able to convert a timestamp to broken-down time in multiple different time zones in a multi-threaded program. My plan was to use the localtime_rz and mktime_z functions included in the tzcode distribution, but I found that while localtime_rz is slightly faster than glibc's localtime_r, mktime_z is substantially slower than mktime. Poking around in the code, I was a bit surprised to find mktime_z just does a binary search of the whole time_t range, though I did appreciate this comment: Adapted from code provided by Robert Elz, who writes: The "best" way to do mktime I think is based on an idea of Bob Kridle's (so its said...) from a long time ago. does a binary search of the time_t space. Since time_t's are just 32 bits, its a max of 32 iterations (even at 64 bits it would still be very reasonable). I ended up writing my own localtime_rz and mktime_z with the assumption that time_t is always 64-bits and neither would ever be used with leap seconds (which was fine for the problem at hand) but that got me thinking: how hard would it be to extend that to support leap seconds. I ended up getting something that appears to work; you can see the results here: https://github.com/tphelps/tz64/ The performance improvement is substantial; on my laptop (Intel i7-8550U, 4GHz) it takes about 35ns to convert a struct tm to a time_t; whereas mktime_z takes about 3,300ns. Which, finally, brings me to my question: is there any interest in reworking tzcode's mktime to use a more efficient algorithm? I realize that it's a reference implementation, so correctness is very important, and you folks might not want to make such a significant change. If, however, you are interested, perhaps we can review what I've done to find and address any shortcomings in the approach I've taken (or to decide that it's fatally flawed, of course) before trying to use them in localtime.c. Any thoughts? -Ted

3 6

[tz-announce] 2022d release of tz code and data available
by Paul Eggert via tz-announce Sept. 24, 2022

Sept. 24, 2022

The 2022d release of the tz code and data is available. This release reflects the following changes: Briefly: Palestine transitions are now Saturdays at 02:00. Simplify three Ukraine zones into one. Changes to future timestamps Palestine now springs forward and falls back at 02:00 on the first Saturday on or after March 24 and October 24, respectively. This means 2022 falls back 10-29 at 02:00, not 10-28 at 01:00. (Thanks to Heba Hamad.) Changes to past timestamps Simplify three Ukraine zones to one, since the post-1970 differences seem to have been imaginary. Move Europe/Uzhgorod and Europe/Zaporozhye to 'backzone'; backward-compatibility links still work, albeit with different timestamps before October 1991. Here are links to the release files: https://www.iana.org/time-zones/repository/releases/tzcode2022d.tar.gz https://www.iana.org/time-zones/repository/releases/tzdata2022d.tar.gz https://www.iana.org/time-zones/repository/releases/tzdb-2022d.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 0fc8f915a527d1d6610b9545aa3958cf89511927 dated 2022-09-23 12:02:57 -0700 and tagged '2022d' in the development GitHub repository at <https://github.com/eggert/tz>. Here are the SHA-512 checksums for the release files: 54491ef8dbab7c41754eb3f2990b8ccb2a10960098c7d78d94375d7f1362540f0d71ba77a46bcaf95f419f8d01a23bdf940cdc9c7906c23ad6c40cd1c788b1c2 tzcode2022d.tar.gz f0d9f1dc6b7613598a861a3860f249e5beff75d8c4bb12bae21018ee617044cf25065dff08f81b0e6ed2c43602f2166dd6407a989a369a004e068260f2eece30 tzdata2022d.tar.gz bb1873550d5bb3fb0d1b595f321e2e90e63bba11bbd80a8c3d440903cb7a9ecd1db58644751b0925bc2854c2b17107238b3a2b9d5f8f91188e3b80b0b67f2673 tzdb-2022d.tar.lz Here are the GPG digital signatures for the release files: -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmMuBjEACgkQ7ZfpDmKq fjQAEg//W+Dm8r7XHCZXNi/H87476tS4AZ8LiggRU+SAnkm7JDj7rAHhpR5uAO1s e1wXaKSMsfxHtUHCjmDn9qguGA3OPUaySaIw6+BGplfCAXarBj5tCrwsiF6T0tvY z3gTeu2E1DDzz2vree0y3boX9aTuFGmc9Ru+dUOVR/O4dun5RbN4VvKBdVRBIOpJ nXVSB12ZRRuTRoXeoSmKfXNPocM330yquWu/HvEdoWSspnx1hptY53DmG+BrSwvS 4uGfqTs5D4zleOaFXLNFb2igwmTS7g2nJGusud7ClXNeU8PkBUiS8ptFTX2n+TnQ SQxuVh+hTlMUjOMFWAkWxDPPRMM4sH3IgRj3y8sgSVOEaCfP9CGH0AgrgH6UuTlQ RtlQeFW2iYSyzmnvatEoE4tGu0bPjnJD7cnMFj6JWdJmks/A8ZgkkOCSAQ9tnqRj pMih15BOeRiQD6JSf8UJ7CIVhe44pN52DKIVZUxFzd6wyj25QRzF7yARykXYUAb6 quwy/WqkLV56MuZ21BuSWPXra1VXXygDctYHPSUuoXdHPEqY5BYtDNXD77e2vPiM X3oLLFe1j4rlY1tWQOymAFWJXL580l+kgzCS8Hf2cbPC0/on4Juol4rY4EB3RZHc FxhWPNDu9E1IIS4BP0BRLG56PQ9sGCy9NUFyxcimWBG2ApXHPTA= =MG7s -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmMuBkQACgkQ7ZfpDmKq fjQPuQ/9HOGp0hSxUup5vWDn0Eb5LChS+5J3nP1e6f6hjghGtOotMEmg/4Fc0w1w HqdEniaTzxMa//UxArnHrUP+rXNiodUIiykHXWXxGcEuYF3VX/PtFfBtodLRszRS gTbzRABrlzuyEvecX1/0rU+msi4IHAFV+/YFMv+2C5Fp8ra/nkailbN667m1MG6y HmHLov/lOfuZNKWGa1Z6B/gr7Oh3LmeQ+sPJc0v4OvKmPEER6E+Zwc4DvMJechD4 IJmdwkfHngyjgDHI2my8lvxWkWQnYgC2WXM/tZ/FAMSErakpwnpUo0FbzLs4Dfy1 WERS59Xqi8tiA+7hLxMGPirnXAF21hyb+L2E96FOVDv/ebQrwkfdekGN6MNYPLpy +pCbfwC+0zcfPc9BbvyxxPwdmpvzsFBQ3VwFO/M0jJQ8K6S/5OkTOi5OuKYaKVhV Wb6cXDE1Mf4EctOW/lyuA+xxJLRadjqFg6Cc5brFKLm7bf05JevGi/oboVo8sXIh qdYc8kqEEBdOzymeSwuo71jNaAYK2hN4hsDaJfxHQdObRx2p53AMTu+99pYiYHiT jOEXBQv6HwA4ve1oz2iMqsS2WTNfLctIVxYsFOLDXVHBkgxm5J9FQqJRvoDc30PK eYNRahWQ3MBGtaDRHQU5Vhru+au5CywihGTDvItvLpgVAO5LwJs= =VLZ9 -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEfjeSqdis99YzvBWI7ZfpDmKqfjQFAmMuBkgACgkQ7ZfpDmKq fjSHIxAAplxEGo1Sl94i7OXjVBJameXZ3p2J5AQ7LN3P1N8BOYiCPDaQzfjXprix Ev9Rm+FUOBx0ZDvm03av0MvH1b2sWhFp3VtxcKFiTpyGCRBOPgSG7IsKiLndlcgh eFFc1IOXWPdm9nTma9XxOI0y2oAl8xdK6F43cULpBslkjPyB5diBu/emI28sJ5Jo d8rgCH9mrvBKPCOgOC56T3rSsCXU71lon49l44tjfBw9FcQRgdB4GRnBKpJYPMqb QUZT6WI6sbRqWrKyVxNC8zks4n1zq0eFhFXSlXFHKUicR63h/PoCEzWX3v2yxZc2 gAFq9cb2Ivab/wz4l1khot9PZBdvYSe4fzcbmNG97fmqkLEg3Lw2ZuqEZBYv3WLn yGnPmDQGwvLwNe28nrAJwmZDccC348XQ8mO8wc5FOk+pWmSx0mW/trgDADTdgK89 pgN9chj3OjC1yagMG8DZWu6LoV+jOdrqI/hRAE9ws/z3iizfebadNYVzN8dLt4xk 7bcKUQ9oddA/kHBtDg28LCEd/3yodVocRpltP2JJgbDdJd8KjrGdBlp/VGbIOCpi KM3N8IXZPVfO/7oUGhFYWCskVLgWQSvwpBXI2+J3fFq3NYHlV20zXhaDeRDYLqxD wNUvDpPZZ8nTO5bhr5AYsW5fa7+tz/itQw/foju2/lp/Wh9XLL8= =sBcz -----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 DATAFORM=rearguard tailored_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

US DoT report on time zone impacts and uniformity
by Tim Parenti Sept. 23, 2022

Sept. 23, 2022

Time zones eking their way into popular media again… CNN reports tonight that officials at the US Department of Transportation are working on translating their official time zone boundaries (described in regulatory texts) into the form of an official map, after — gasp! — "investigators found no single map accurately showing the boundaries nationwide", along with several inconsistencies on their own websites. https://www.cnn.com/2022/09/22/politics/time-zone-map-transportation-depart… Of course, beneath the surface, this was just one finding from a 28-page report published by the DoT's Office of Inspector General on Tuesday: DOT Can Improve Processes for Evaluating the Impact of Time Zone Changes and Promoting Uniform Time Observance, 2022-09-20 https://www.oig.dot.gov/sites/default/files/DOT%20Time%20Zone%20Final%20Rep… Among the other major findings of the report are that DoT is "responsible for evaluating whether requests to change time zones serve the convenience of commerce," but lacks "written guidance for how…officials should validate the information provided by petitioners" when a time zone change is proposed, making it difficult to address the potential impacts associated with a change. The report recommended "evaluat[ing] the relevance of the convenience of commerce questions" developed to weigh such considerations, and updating the questions, if necessary, to "reflect modern commerce-related impacts of time zone changes". And while DoT finds it "has no role in DST exemptions, …it is responsible for fostering and promoting uniform time observance, including DST", but again lacks "processes for tracking or monitoring localities" whose observances deviate from those assigned. The absence of an "official repository of detailed maps" was found to be limiting the DoT's ability to monitor "non-uniform time observance" as well as the public's ability to identify it. A note in an appendix further points out that a portion of the official Central–Mountain time zone boundary through Stanley County, South Dakota (near Pierre) refers to a railway river crossing… and that the railway went out of business in 1995. -- Tim Parenti

1 0

Timezone name changes
by Ростислав Салабай Sept. 22, 2022

Sept. 22, 2022

Greetings! Due to the ongoing war in Ukraine, for a few months now, Ukrainian based transliterations of city names are getting more and more commonly used. Firstly, it started with Kyiv, and now other names follow along. Some names like Odessa or Kharkov are still more commonly using Russian transliterations, but two other cities, Uzhgorod and Zaporizhzhia, on tz timezone list, aren't like that. It can be seen online, for example, on social media or on platforms like Google Analytics. So, I think that it's time to change Europe/Zaporozhye to Europe/Zaporizhzhia and Europe/Uzhgorod to Europe/Uzhhorod. Of course, while leaving old timezone names as links to new ones, for fallback reasons

2 1

Re: [tz] winter & Summer time in the State Of Palestine
by heba.hamad＠mtit.gov.ps Sept. 20, 2022

Sept. 20, 2022

the text is correct and matches with the cabinet decision that is attached previously ,so kindly ignore the illustration we will correct the illustration in the announcement and send the link again but to keep time we confirm that the text is correct we hope the TZ release will be issued as soon as possible في الأحد, سبتمبر 04, 2022 17:53 EDT, Paul Eggert <eggert(a)cs.ucla.edu> كتب: On 9/4/22 06:00, Michael H Deckers wrote: > The illustration on that page makes it clear that the > Arabic text is probably meant to say > winter time starts with the value 2 am on Saturday 2022-10-29 > rather than > the switch to winter time occurs when summer time would > have assumed the value 2 am on Saturday 2022-10-29 > as it was wrongly interpreted in the proposed changes > to Rule Palestine. Ouch. My guess is just the opposite. That is, my guess is that the illustration[1] (attached) in [2] is wrong, and I guess that the text is correct. That is, I think the illustration should show the clock moving backward from 2am to 1am, not from 3am to 2am. Heba Hamad, can you please confirm which is correct here? The illustration or the text? The text matches the document you already sent us. Thanks. [1]: https://mtit.pna.ps/Content/imgs/news/-8585393378987544401IMG-20220903-WA00… [2]: https://mtit.pna.ps/Site/New/1453

9 21

Re: [tz] tz Digest, Vol 132, Issue 8
by Paul Eggert Sept. 12, 2022

Sept. 12, 2022

On 9/11/22 23:22, Vaibhav Shrivastava wrote: > This case is Failing: (we have our custom batch to parse iana files). I suggest modifying the custom batch script to do the equivalent of the following 'sed' command first thing: sed 's/#.*//; /^[[:space:]]*$/d' That is, remove all comments and empty lines. This might work around the bug in the script. > Zone Africa/Sao_Tome 0:26:56 - LMT 1884 > #STDOFF -0:36:44.68 > --> > comment in the middle of rule > -0:36:45 - LMT 1912 Jan 1 00:00u # Lisbon MT > 0:00 - GMT 2018 Jan 1 01:00 > 1:00 - WAT 2019 Jan 1 02:00 > 0:00 - GMT Surely the bug is more complicated than merely comments before a continuation line, as tzdata has had comments like that for decades. For example, something like the following has been in the 'europe' file since 1995. Zone Europe/Athens 1:34:52 - LMT 1895 Sep 14 1:34:52 - AMT 1916 Jul 28 0:01 # Athens MT 2:00 Greece EE%sT 1941 Apr 30 1:00 Greece CE%sT 1944 Apr 4 2:00 Greece EE%sT 1981 # Shanks & Pottenger say it switched to C-Eur in 1981; # go with EU rules instead, since Greece joined Jan 1. 2:00 EU EE%sT

1 0

Re: [tz] tz Digest, Vol 132, Issue 8
by vaibhav shrivastava Sept. 9, 2022

Sept. 9, 2022

Helllo, There is #STDOFF comment introduced for some of the tzdata in the middle of the rule. Causing parsing issue in tzdata to create correct utc and dst information. Regards, Vaibhav On Fri, 9 Sep 2022, 03:19 , <tz-request(a)iana.org> wrote: > Send tz mailing list submissions to > tz(a)iana.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mm.icann.org/mailman/listinfo/tz > or, via email, send a message with subject or body 'help' to > tz-request(a)iana.org > > You can reach the person managing the list at > tz-owner(a)iana.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tz digest..." > > > Today's Topics: > > 1. tz database. (Kiley Walbom) > 2. Re: tz database. (Kim Davies) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 7 Sep 2022 16:35:58 +0000 > From: Kiley Walbom <kiley.walbom(a)taxography.com> > To: Paul Eggert via tz <tz(a)iana.org> > Cc: Bradley Curl <bcurl(a)taxography.com> > Subject: [tz] tz database. > Message-ID: > < > MWHPR17MB19834868386572D03AB05182E4419(a)MWHPR17MB1983.namprd17.prod.outlook.com > > > > Content-Type: text/plain; charset="us-ascii" > > Hi Paul, > > My colleague is having issues subscribing to the TZ database. > He keeps getting a "Forbidden" error message when registering. > And he sent an email to mailman-request(a)iana.org<mailto: > mailman-request(a)iana.org> and received and undeliverable notice. > > bcurl(a)stopwatchmaps.com<mailto:bcurl@stopwatchmaps.com> > > Any advice you could offer? > > > Kiley Walbom > Lead Cartographer > Geographic Information Systems Dept. > Taxography, INC > 6353 N. Rosebury Ave > St Louis, MO 63105 > 314-863-9292 ext. 130 > 314-925-1751 (Direct) > > "A map is the greatest of all epic poems. Its lines and colors show the > realization of great dreams." > --Gilbert Grosvenor, Editor, National Geographic, 1903-1954 > > [cid:image001.jpg@01D8C1F4.71CB4EC0] > Address standardization and tax jurisdiction assignment web services. > Taxography uses county supplied parcel-level data, geographic boundaries, > and assessor verified address-level jurisdiction assignments to provide you > with the most current, authoritative, and auditable jurisdiction > assignments possible. > > >

2 1

Re: [tz] tz database.
by Kim Davies Sept. 8, 2022

Sept. 8, 2022

Hello, You can subscribe at https://mm.icann.org/mailman/listinfo/tz by submitting the address through the form. I hope this helps. I believe the mailman-request(a)iana.org<mailto:mailman-request@iana.org> method is long deprecated, did you see that in documentation somewhere that we need to update? kim -- Kim Davies VP, IANA Services, ICANN President, PTI From: tz <tz-bounces(a)iana.org> on behalf of Kiley Walbom via tz <tz(a)iana.org> Reply to: Kiley Walbom <kiley.walbom(a)taxography.com> Date: Thursday, 8 September 2022 at 2:47 pm To: Paul Eggert via tz <tz(a)iana.org> Cc: Bradley Curl <bcurl(a)taxography.com> Subject: [tz] tz database. Hi Paul, My colleague is having issues subscribing to the TZ database. He keeps getting a “Forbidden” error message when registering. And he sent an email to mailman-request(a)iana.org<mailto:mailman-request@iana.org> and received and undeliverable notice. bcurl(a)stopwatchmaps.com<mailto:bcurl@stopwatchmaps.com> Any advice you could offer? Kiley Walbom Lead Cartographer Geographic Information Systems Dept. Taxography, INC 6353 N. Rosebury Ave St Louis, MO 63105 314-863-9292 ext. 130 314-925-1751 (Direct) "A map is the greatest of all epic poems. Its lines and colors show the realization of great dreams." --Gilbert Grosvenor, Editor, National Geographic, 1903-1954 [cid:image001.jpg@01D8C392.287EF4C0] Address standardization and tax jurisdiction assignment web services. Taxography uses county supplied parcel-level data, geographic boundaries, and assessor verified address-level jurisdiction assignments to provide you with the most current, authoritative, and auditable jurisdiction assignments possible.

1 0

tz database.
by Kiley Walbom Sept. 7, 2022

Sept. 7, 2022

Hi Paul, My colleague is having issues subscribing to the TZ database. He keeps getting a "Forbidden" error message when registering. And he sent an email to mailman-request(a)iana.org<mailto:mailman-request@iana.org> and received and undeliverable notice. bcurl(a)stopwatchmaps.com<mailto:bcurl@stopwatchmaps.com> Any advice you could offer? Kiley Walbom Lead Cartographer Geographic Information Systems Dept. Taxography, INC 6353 N. Rosebury Ave St Louis, MO 63105 314-863-9292 ext. 130 314-925-1751 (Direct) "A map is the greatest of all epic poems. Its lines and colors show the realization of great dreams." --Gilbert Grosvenor, Editor, National Geographic, 1903-1954 [cid:image001.jpg@01D8C1F4.71CB4EC0] Address standardization and tax jurisdiction assignment web services. Taxography uses county supplied parcel-level data, geographic boundaries, and assessor verified address-level jurisdiction assignments to provide you with the most current, authoritative, and auditable jurisdiction assignments possible.

1 0

Amsterdam timezone prior to 1937 incorrect?
by Loek Engels Sept. 6, 2022

Sept. 6, 2022

Hi, Between 2022a an b the timezone info for Europe/Amstedam is removed: Z Europe/Amsterdam 0:19:32 - LMT 1835 The timezone info for Brussels around that date differs from Amsterdams timezone info. Determining the timezone information for dates around that period on my Linux system in python returns since the latest update an offset of 0 minutes as opposed to the 19 minutes previously. Is the removal for this timezone information intentional or a bug? Regards, Loek

3 2

winter & Summer time in the State Of Palestine
by heba.hamad＠mtit.gov.ps Sept. 4, 2022

Sept. 4, 2022

Dear Sir, We would like to inform you that winter time will begin in Palestine from Saturday 10-29, 02:00 AM by 60 minutes backwards Also the state of Palestine adopted the summer and winter time for the years: 2023,2024,2025,2026 as following below: * Summer time will begin in Palestine from Saturday, 02:00 AM by 60 minutes forwards as shown in the table below. * winter time will begin in Palestine from Saturday ,02:00 AM by 60 minutes backwards as shown in the table below YearSummer TimeWinter Time202325/328/10202430/326/10202529/325/10202628/324/10 .Kindly find the attachment below that includes the decision of the Palestinian cabinet With Respects,

5 10

Mexico may eliminate DST next year- except parts of some northern states
by wtz＠worldtimezone.com Sept. 2, 2022

Sept. 2, 2022

According to some news published on Wednesday, July 6, 2022 Mexico may eliminate DST next year- except parts of some northern states. "AMLO sends bill to eliminate daylight saving; Mexico to return to 'God's time'" https://mexiconewsdaily.com/news/amlo-sends-bill-to-eliminate-daylight-savi… https://www.reuters.com/world/americas/mexico-president-presents-bill-elimi… "Mexico president presents bill to eliminate daylight saving time" "It's likely that the clocks won't change next year in most states" "The bill only requires a simple majority to pass the federal legislature, meaning that it is likely to become law. With the support of its allies, the ruling Morena party commands a majority in both the lower and upper houses. Energy Minister Rocío Nahle and Health Minister Jorge Alcocer appeared at the president's morning press conference on Tuesday to present arguments in favor of getting rid of the twice-a-year time change...... ..................... However, God's clock and health worries may not apply in parts of some northern states where clock changes have been synchronized with states in the southern U.S. to facilitate cross-border trade and other connections. Energy Minister Nahle said on Tuesday that there would continue to be exceptions in some northern border municipalities." Regards, WorldTimeZone.com team

3 2