- tz - lists.iana.org

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