December 2021 - tz - lists.iana.org

(no subject)
by Cool Gab19 05 Sep '24

05 Sep '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 7

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] Wrong name of timezone
by Pierpaolo Bernardi 11 Apr '22

11 Apr '22

Il giorno 25 ottobre 2021, alle ore 16:58, Igor Melnyk via tz <tz(a)iana.org> ha scritto: >But Ukraine has the Ukrainian language and Kiev is in russian language. The correct name of the capital city of Ukraine is Kyiv. Kiev is English language, as every other name in the db, not russian. It is only a coincidence that the English name is more similar to russian than to Ukrainian.

6 5

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

[PATCH] Allow complication with tcc
by Arthur Williams 31 Dec '21

31 Dec '21

In zic.c, some multi-line strings were surrounded in parenthesis which prevented tcc from parsing it. Maybe this is a complier bug, but don't think we gain anything by having the paren so just removed them. --- zic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/zic.c b/zic.c index 1ab636be..867c8d18 100644 --- a/zic.c +++ b/zic.c @@ -990,9 +990,9 @@ random_dirent(char const **name, char **namealloc) char const *src = *name; char *dst = *namealloc; static char const prefix[] = ".zic"; - static char const alphabet[] = ("abcdefghijklmnopqrstuvwxyz" + static char const alphabet[] = "abcdefghijklmnopqrstuvwxyz" "ABCDEFGHIJKLMNOPQRSTUVWXYZ" - "0123456789"); + "0123456789"; enum { prefixlen = sizeof prefix - 1, alphabetlen = sizeof alphabet - 1 }; int suffixlen = 6; char const *lastslash = strrchr(src, '/'); -- 2.34.1

2 1

Re: [tz] Change Request: Europe/Kiev to Europe/Kyiv
by John Hawkinson 15 Dec '21

15 Dec '21

A bit of necroposting from my August 2020 email (quoted in full below): > 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 [people]. Has anyone done any work on this, or given thought to it? Serhii Trykoza (hopefully cc'd)'s github PR from the last hour (https://github.com/eggert/tz/pull/35, copied far below) raises the issue again. Please note that the tz project does not use github PRs for issue tracking or commit management, so the PR will likely be closed in short order, which is not an indication of merit. Speaking of boilerplates, I want to again suggest that if this is going to continue to be the project policy, there should be a github pull-request template that makes it clear pull requests are not considered appropriate. Also, when you create a pull request on github now, it reports, "Be sure to review the contributing guidelines." with a hyperlink to https://github.com/eggert/tz/blob/228a93f759cd5f2b0cca9e05eeee3d7cdea07ebf/…. It is not until the last paragraph of that file that any mention is made of pull requests ("[p]lease do not create [them]"), and the fact that the it's a plain text file (rather than CONTRIBUTING.md in markdown) makes it feel pretty unfriendly in the github world. Convertinf the file to markdown and making the "please don't use github pull requests" the first thing, rather than the last thing, would help to get the point across. (Indeed, perhaps that should be the *only* thing in the file that github links to.) -- jhawk(a)alum.mit.edu John Hawkinson John Hawkinson <jhawk(a)alum.mit.edu> wrote on Sat, 15 Aug 2020 at 18:52:58 EDT in <20200815225258.GA62055(a)alum.mit.edu>: > Date: Sat, 15 Aug 2020 18:52:58 -0400 > From: John Hawkinson <jhawk(a)alum.mit.edu> > To: Paul Eggert <eggert(a)cs.ucla.edu>, Victor Perov <vic.gald(a)gmail.com> > Cc: Time zone mailing list <tz(a)iana.org> > Subject: Re: [tz] Change Request: Europe/Kiev to Europe/Kyiv > Message-ID: <20200815225258.GA62055(a)alum.mit.edu> > In-Reply-To: <eggert/tz/pull/27/c673663957(a)github.com> > <cefc7f01-a3e9-f2a4-9ab9-5288147f994a(a)cs.ucla.edu> > > 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 Serhii Trykoza <notifications(a)github.com> wrote on Mon, 6 Dec 2021 at 08:17:35 EST in <eggert/tz/pull/35(a)github.com>: > Date: Mon, 06 Dec 2021 05:17:35 -0800 > From: Serhii Trykoza <notifications(a)github.com> > To: eggert/tz <tz(a)noreply.github.com> > Cc: Subscribed <subscribed(a)noreply.github.com> > Subject: [eggert/tz] KyivNotKiev (PR #35) > Reply-To: eggert/tz > <reply+AAJWHPTK2DO6A5B34PZOC3N7XHXG7EVBNHHD7Z4WBI(a)reply.github.com> > Message-ID: <eggert/tz/pull/35(a)github.com> > X-GitHub-Sender: strikoza > > In September 2020, the English Wikipedia switched from using Kiev to Kyiv. > > https://en.wikipedia.org/wiki/KyivNotKiev > You can view, comment on, or merge this pull request online at: > > https://github.com/eggert/tz/pull/35 > > -- Commit Summary -- > > * KyivNotKiev - In September 2020, the English Wikipedia switched from using Kiev to Kyiv - https://en.wikipedia.org/wiki/KyivNotKiev > > -- File Changes -- > > M .gitignore (2) > M europe (4) > M theory.html (2) > M zone.tab (2) > M zone1970.tab (2) > > -- Patch Links -- > > https://github.com/eggert/tz/pull/35.patch > https://github.com/eggert/tz/pull/35.diff > > -- > You are receiving this because you are subscribed to this thread. > Reply to this email directly or view it on GitHub: > https://github.com/eggert/tz/pull/35

4 9

[PATCH] Fix "el ds" typo in man pages
by Paul Eggert 14 Dec '21

14 Dec '21

This fixes a typo that I introduced in 2014 when fixing glitches with '-' and italics in man pages. The typo is visible only when using traditional troff (as opposed to groff-compatible processors). --- date.1 | 2 +- newctime.3 | 2 +- newstrftime.3 | 2 +- newtzset.3 | 2 +- time2posix.3 | 2 +- tzfile.5 | 2 +- tzselect.8 | 2 +- zdump.8 | 2 +- 8 files changed, 8 insertions(+), 8 deletions(-) diff --git a/date.1 b/date.1 index 432cab1..1ecd63a 100644 --- a/date.1 +++ b/date.1 @@ -5,7 +5,7 @@ date \- show and set date and time .if n .nh .if n .na .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- .B date [ .B \*-u diff --git a/newctime.3 b/newctime.3 index cc56e2c..1b1790f 100644 --- a/newctime.3 +++ b/newctime.3 @@ -4,7 +4,7 @@ asctime, ctime, difftime, gmtime, localtime, mktime \- convert date and time .SH SYNOPSIS .nf .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- .B #include <time.h> .PP .BR "extern char *tzname[];" " /\(** (optional) \(**/" diff --git a/newstrftime.3 b/newstrftime.3 index 887aba5..d68bc33 100644 --- a/newstrftime.3 +++ b/newstrftime.3 @@ -41,7 +41,7 @@ strftime \- format date and time .SH SYNOPSIS .nf .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- .B #include <time.h> .PP .B "size_t strftime(char *restrict buf, size_t maxsize," diff --git a/newtzset.3 b/newtzset.3 index 05aa350..8aaa0ff 100644 --- a/newtzset.3 +++ b/newtzset.3 @@ -4,7 +4,7 @@ tzset \- initialize time conversion information .SH SYNOPSIS .nf .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- .B #include <time.h> .PP .B timezone_t tzalloc(char const *TZ); diff --git a/time2posix.3 b/time2posix.3 index fbb5766..2ea7edc 100644 --- a/time2posix.3 +++ b/time2posix.3 @@ -4,7 +4,7 @@ time2posix, posix2time \- convert seconds since the Epoch .SH SYNOPSIS .nf .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- .B #include <time.h> .PP .B time_t time2posix(time_t t); diff --git a/tzfile.5 b/tzfile.5 index e2f11b4..550b31d 100644 --- a/tzfile.5 +++ b/tzfile.5 @@ -10,7 +10,7 @@ tzfile \- timezone information \\$3\*(lq\\$1\*(rq\\$2 .. .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- The timezone information files used by .BR tzset (3) are typically found under a directory with a name like diff --git a/tzselect.8 b/tzselect.8 index a1ec8d0..69514e2 100644 --- a/tzselect.8 +++ b/tzselect.8 @@ -3,7 +3,7 @@ tzselect \- select a timezone .SH SYNOPSIS .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- .B tzselect [ .B \*-c diff --git a/zdump.8 b/zdump.8 index a5e2042..131a6cb 100644 --- a/zdump.8 +++ b/zdump.8 @@ -17,7 +17,7 @@ zdump \- timezone dumper \\$3\*(lq\\$1\*(rq\\$2 .. .ie \n(.g .ds - \f(CW-\fP -.el ds - \- +.el .ds - \- The .B zdump program prints the current time in each -- 2.32.0

1 0

[PROPOSED] Fix Y2242 bug in tzdb tarball generation
by Paul Eggert 13 Dec '21

13 Dec '21

Use pax format so that ‘make tarballs’ will still work after the year 2242. Without this patch, a far-future ‘make tarballs’ would fail for the same reason the following fails now with GNU tar: $ touch -d 2242-03-16T12:56:32Z future $ tar --format=ustar -cf tar future tar: value 8589934592 out of time_t range 0..8589934591 tar: Exiting with failure status due to previous errors This patch doesn’t change the tarball format for today’s releases since we don’t use any features requiring pax format, which means the tarballs stick to the ustar subset of pax. Although this issue was exposed by the recent switch to ustar format, the Y2242 bug has been present since the tzdb project began, due to historical tar format expiring in 2242 and to POSIX and GNU coming up with incompatible extensions to deal with this expiration. * Makefile (GNUTARFLAGS): Switch from --format=ustar to --format=pax --pax-option='delete=atime,delete=ctime'. * NEWS: Update description of tarball format change. --- Makefile | 3 ++- NEWS | 7 +++++-- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index d30227a..23dcc14 100644 --- a/Makefile +++ b/Makefile @@ -466,7 +466,8 @@ OK_LINE= '^'$(OK_CHAR)'*$$' # Flags to give 'tar' when making a distribution. # Try to use flags appropriate for GNU tar. -GNUTARFLAGS= --format=ustar --numeric-owner --owner=0 --group=0 \ +GNUTARFLAGS= --format=pax --pax-option='delete=atime,delete=ctime' \ + --numeric-owner --owner=0 --group=0 \ --mode=go+u,go-w --sort=name TARFLAGS= `if tar $(GNUTARFLAGS) --version >/dev/null 2>&1; \ then echo $(GNUTARFLAGS); \ diff --git a/NEWS b/NEWS index edb9a1d..1106ef6 100644 --- a/NEWS +++ b/NEWS @@ -26,9 +26,12 @@ Unreleased, experimental changes 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 " ". For details about ustar format, please see + 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_…>. + <https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_…>. Changes affecting documentation and commentary -- 2.33.1

2 1