August 2021 - tz - lists.iana.org

(no subject)
by Cool Gab19 08 Nov '24

08 Nov '24

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

Re: [tz] Morocco : Ramdan Time Change 2021
by Paul Eggert 15 Mar '23

15 Mar '23

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

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

14 Nov '22

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

Re: [tz] iana build failures on Windows
by Paul Eggert 02 Nov '22

02 Nov '22

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

Re: [tz] Change Request: Europe/Kiev to Europe/Kyiv
by John Hawkinson 18 Mar '22

18 Mar '22

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

10 13

Italy April 1944 discrepancy between comment and data
by Alois Treindl 05 Oct '21

05 Oct '21

For Italy in 1944 zone Europe/Rome there is a discrepancy between the comment and the data. comment: # From Paul Eggert (2016-10-27): # Go with INRiM for DST rules, except as corrected by Inglis for 1944 # for the Kingdom of Italy. This is consistent with Renzo Baldini. # Model Rome's occupation by using C-Eur rules from 1943-09-10 # to 1944-06-04; although Rome was an open city during this period, it # was effectively controlled by Germany. Data for Italy is Rule Italy 1944 only - Apr 2 2:00s 1:00 S Data for C-Eur is: Rule C-Eur 1944 1945 - Apr Mon>=1 2:00s 1:00 S where Mon>=1 in 1944 is April 3. So Rome is NOT following C-Eur. I think the rule for Itay is right, only the comment is misleading.

4 9

Undoing the effect of the new alike-since-1970 patch
by Paul Eggert 21 Sep '21

21 Sep '21

There's been a clear need expressed to support tzdb users who would rather not deal with the effects of the recently-proposed alike-since-1970 patch. On the other hand there are also fairness and guideline-oriented reasons for the patch, which was originally discussed and installed with more than our usual care and review. Because of the extensive followup discussions I don't see how a single version could be appealing to both sides of this disagreement. So I propose we add a Makefile or similar build-time option to let tzdb users have it either way. Set the flag one way, and it will be as if the recently-proposed changes did not occur. Set it the other way, and you'll get the changes. This will be similar to our vanguard/rearguard support, which helped address a similar disagreement back in 2018. We could even control things via the existing vanguard/rearguard build-time option; that might be simpler. If you have ideas about what the the option's specific effects should be, please let me know. If there is support for this idea, I expect to be able to implement this option soon, in plenty of time before any urgent change due to a real-world rule change arrives. Like most compromises, I expect this approach to not be entirely satisfactory to anybody. However, I hope it helps us move forward together.

15 39

Re: [tz] No leap second on 2021-12-31
by Kerry Shetline 14 Sep '21

14 Sep '21

What’s interesting is that the Earth is undergoing an odd span of time during which it has been spinning a bit faster instead of slowing down. If this keeps up, not only will it be a while until we see another leap second, but in a few years we might experience the first negative leap second, where a second is dropped from the end of the last minute just before 00:00 UTC. > Per IERS, Bulletin C 62 (2021-07-05) > https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.62 > > ?and forwarded below. > > A patch updating leap-seconds.list from NIST is attached, and is installed > in the development repository. > > -- > Tim Parenti

3 2

Historical fix for Tonga
by Tim Parenti 14 Sep '21

14 Sep '21

First, a quick clerical patch: 0001, attached, fixes the placement of a comment which got shuffled around in the lead-up to publishing the changes for South Sudan in 2021a. Patch 0003 relates to Tonga, and comes from some of the links P Chan shared to 1957–1963 editions of The Air Almanac: https://mm.icann.org/pipermail/tz/2021-February/029866.html On Thu, 25 Feb 2021 at 03:43, P Chan <legco(a)outlook.com> wrote: > 1960 Nov (1962.1-4) > https://books.google.com/books?id=bVgtWM6kPZUC&pg=SL1-PA20 > 1961 Mar (1962.5-8) > https://books.google.com/books?id=W2nItAul4g0C&pg=SL1-PA20 When looking around at how this data was presented for other regions, I noticed on the preceding pages (listing "Places Fast on GMT", i.e., east of Greenwich) in some of the earlier editions provided that Tonga was listed at GMT+12:20. The peculiar offset stuck out, and I quickly noticed that some of the later editions of the same tables had it at GMT+13. A quick bisection puts the changeover, as far as The Air Almanac contemporaneously reckoned it, between November 1960 and March 1961. Previously, our data had Tonga transitioning to UT+13 in 1941 based on a quotation from a 1997 news article. Although this differs from what the Almanac suggests by some 20 years, the article does mention a change coincident with the New Year, and that Tāufaʻāhau Tupou IV was Crown Prince at the time. As his predecessor and mother, Queen Sālote Tupou III, reigned from 1918-04-05 to 1965-12-16, a possible transition of 1961-01-01 still jives with the gist of the article, even if the specific year was perhaps wrong or just misprinted. For what it's worth, our commentary already noted that Shanks & Pottenger had put the transition even later, at 1968-10-01. Although of course we don't know how they arrived at that date, given that they did, 1961 seems rather less out-of-place than it otherwise might. The attached patch 0003 makes this adjustment, while more fully documenting and comparing the conflicting sources. Thanks again to P Chan for pointing us to these resources. I wasn't expecting to get a "bonus" correction out of it, but one never knows quite what will catch the eye… -- Tim Parenti

3 3

[PATCH 1/8] * tzfile.5: Fix prefix/suffix typo (thanks to Ian Abbott).
by Paul Eggert 14 Sep '21

14 Sep '21

--- tzfile.5 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tzfile.5 b/tzfile.5 index b4952d5..ec78689 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -134,7 +134,7 @@ bytes that represent time zone designations, which are null-terminated byte strings, each indexed by the .B tt_desigidx values mentioned above. -The byte strings can overlap if one is a prefix of the other. +The byte strings can overlap if one is a suffix of the other. The encoding of these strings is not specified. .IP * .B tzh_leapcnt -- 2.27.0

2 8