[tz] Re: Add ICU's Etc/Unknown Zone to IANA Time Zone Database?

On 2024-12-08 23:52, Paul Eggert wrote: I suspect we'll need to distinguish 'zdump "-"' (where reading from stdin could be useful) from TZ="-" (where we surely don't want a program to read from standard input merely because it wants the time of day and someone used a squirrelly TZ string). I

[tz] Re: Add ICU's Etc/Unknown Zone to IANA Time Zone Database?

On 2024-12-08 23:45, Paul Eggert wrote: On 2024-12-08 14:06, Brian Inglis via tz wrote: Disallowing these would also likely disallow variations on:  $ zdump /usr/share/zoneinfo/.../...  $ zdump <(...) ... Although it disallows the second variation, that's also true for zdump when bu

[tz] [PROPOSED 6/7] Add missing zdump.o dependency

* Makefile (zdump.o): Depend on private.h. --- Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index e00b0f32..f1ce7abb 100644 --- a/Makefile +++ b/Makefile @@ -1360,8 +1360,8 @@ date.o: private.h difftime.o:private.h localtime.o

[tz] [PROPOSED 2/7] Warn about 2-digit years in strftime man page

* newstrftime.3: Warn more about two-digit years. --- newstrftime.3 | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/newstrftime.3 b/newstrftime.3 index 21aef9d0..e8200095 100644 --- a/newstrftime.3 +++ b/newstrftime.3 @@ -144,6 +144,9 @@ is replaced by the locale

[tz] Re: v2024b Mexico rules

On 2025-01-08 00:28, Ertan Küçükoglu via tz wrote: I wonder if that is the new format and not an error. It's not a new format and is not an error; full month names like "April" have been documented for decades and have worked in zic. That being said, some other converters didn't grok "April"

[tz] [PROPOSED 1/7] Modernize date man page

* date.1: Update the example to next year. Remove duplication of spec with strftime, as this is too much of a pain to maintain separately for what is just a demo; but give an example for clarity. Update list of files accessed, to match current code. --- date.1 | 110 +--

[tz] [PROPOSED 7/7] Fix ctime conformace bug

* asctime.c (ctime): Call localtime and asctime, not localtime_r and ctime_r. --- asctime.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/asctime.c b/asctime.c index 3817182e..1bfcafe9 100644 --- a/asctime.c +++ b/asctime.c @@ -162,5 +162,8 @@ ctime_r(const time_t *timep,

[tz] [PROPOSED 3/7] Stop using \*- in man pages

The \*- portability hassle in man pages is no longer needed, now that groff puts into a PDF file something that cuts and pastes as ASCII minus. Removing this hack simplifies the man pages and is nicer for some man page processors. --- date.1| 16 +++--- newctime.3| 4 +- newstrftim

[tz] [PROPOSED 4/7] newctime doc improvements

* newctime.3: Reorder so that functions are described in a more sensible order, e.g., asctime is explained first and ctime merely defers to it. Also put asctime and ctime later since they are deprecated. Mention that localtime and gmtime return a null pointer on failure. --- newctime.3 | 148

[tz] [PROPOSED 5/7] NetBSD defines STD_INSPIRED functions

* private.h (STD_INSPIRED): Default to 1 on NetBSD, since NetBSD has these functions. --- private.h | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/private.h b/private.h index de816077..0a546e02 100644 --- a/private.h +++ b/private.h @@ -810,7 +810,11 @@ extern long altzon

[tz] Re: Request for inclusion of Trivandrum in the IANA Time Zone Database

On 12/20/24 14:33, Doug Ewell wrote: I wonder at what point it becomes worthwhile to update the theory page to state (or state more clearly) that: (1) duplicate zones or “aliases” are not created simply to honor additional locations that are historically or culturally prominent, populous, or u

[tz] Re: localized date without time

On 2025-02-12 00:53, Alejandro Colomar wrote: alx@devuan:~$ date --date='2023-09-20Z' Wed Sep 20 02:00:00 CEST 2023 Should I just use that? (I probably should...) Yes.

[tz] [PROPOSED] Fix to2050.tzs timestamp in distributed tarball

* Makefile (TZS_DEPS): Remove asctime.c and add localtime.c. --- Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 5473dedd..2aafdc24 100644 --- a/Makefile +++ b/Makefile @@ -615,8 +615,8 @@ TZS_YEAR= 2050 TZS_CUTOFF_FLAG= -c $(TZS_

[tz] [PROPOSED] Fix asctime.o, strftime.o dependencies

* Makefile (asctime.o): Don’t depend on tzfile.h. (strftime.o): Depend on tzdir.h, as it’s included indirectly via localtime.c if MKTIME_MIGHT_OVERFLOW. --- Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 2aafdc24..8faab6ff 100644 --- a/

[tz] Re: Add ICU's Etc/Unknown Zone to IANA Time Zone Database?

On 2024-12-11 08:43, Brian Inglis via tz wrote: So far there don't appear to be any - same content == same timezone Indeed, Makefile's now.ck verifies that every zonenow.tab entry has distinct timestamp behavior. Although not quite the same as checking that every distinct file in /usr/share/z

[tz] Re: Add ICU's Etc/Unknown Zone to IANA Time Zone Database?

I recently discovered that since 2006, the ICU file icu4c/source/tools/tzcode/icuzones has had a line "Zone Etc/Unknown 0 - Unknown"[1]. Any POSIX-like system that feeds this line into 'zic' might run afoul of the recently-proposed TZDB guideline[2] that Etc/Unknown is reserved and is not used

[tz] Re: Iana build failures on Windows

On 2024-12-15 23:11, Manuela Friedrich wrote: localtime.c d:\devsrc\treasure_test\iana\tmp\private.h(872): warning C4005: 'max': macro redefinition C:\Program Files (x86)\Windows Kits\10\include\10.0.16299.0\ucrt\stdlib.h(1300): note: see previous definition of 'max' d:\devsrc\treasure_test\iana

[tz] Re: Iana build failures on Windows

On 2024-12-18 00:34, Manuela Friedrich wrote: unresolved external symbol S_ISREG OK, let's try again. I installed the first attached patch, which I hope fixes that. CFLAGSW = ... -Dssize_t=__int64 ... This doesn't feel right, as ssize_t is the type returned by 'read', and from what I c

[tz] Re: Iana build failures on Windows

On 2024-12-17 07:53, Manuela Friedrich wrote: It's worth noticing that I had to add -DHAVE_SYS_STAT_H=0 to the tools.ini file we use on Windows. Thanks for mentioning that, but unfortunately I don't know why -DHAVE_SYS_STAT_H=0 was needed (I don't use MS-Windows). Some fumbling with Microsof

[tz] Re: Request for inclusion of Trivandrum in the IANA Time Zone Database

On 2024-12-20 09:37, Anish shivaraj via tz wrote: Trivandrum once had its own local mean time before the adoption of Indian Standard Time (IST) The criteria for TZDB inclusion is a distinct timestamp history since 1970 . Unfortunately it wou

[tz] Re: Paraguay may adopt permanent DST soon

On 2024-12-20 00:10, ofrias--- via tz wrote: Is there an estimated date when this change will be published? We should publish the next TZDB release sooner rather than later, because of Paraguay. We don't have an estimated date, though.

[tz] [PROPOSED 2/3] Rename emalloc to xmalloc.

* zic.c (xmalloc, xrealloc, xstrdup): Rename from emalloc, erealloc, estrdup. All uses changed. This ports better to NetBSD, which uses emalloc etc. for other purposes. --- zic.c | 42 +- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/zic.

[tz] [PROPOSED 1/3] Alias asctime, ctime result

I misread C99, and in a 2022-11-30 patch caused asctime and ctime to return different pointers when !SUPPORT_C89. However, C99 and later still require that these two functions return the same pointers, so revert that part of the 2022-11-30 change. * asctime.c (buf_ctime): Remove. All uses replaced

[tz] [PROPOSED 3/3] Pacify gcc -Wcast-qual

NetBSD enables -Wcast-qual when building its localtime.c. * Makefile (GCC_DEBUG_FLAGS): Add -Wcast-qual. * localtime.c (TYPECVT, UNCONST): New macros. (tzname) [2 <= HAVE_TZNAME + TZ_TIME_T]: (update_tzname_etc, settzname, localsub, gmtsub): Use UNCONST instead of casting to char *. --- Makefile

[tz] Re: Notice of a problem with the Asia/Tokyo time zone

From: Patrick BENNY Date: Mon, Jan 20, 2025 at 6:41 PM The Asia/Tokyo time zone seems to have been linked with Australia, probably by mistake. Please see this related difference from the zone1970.tab file, observed when comparing 2024b and 2025a. 186c186 < JP +353916+1394441 Asia/Tokyo --- J

[tz] Re: [tz-announce] 2025a release of tz code and data available

On 2025-01-16 11:48, Paul Eggert wrote: On 2025-01-16 11:21, Geert Hendrickx wrote: On Thu, Jan 16, 2025 at 09:37:50 -0800, Paul Eggert via tz-announce via tz wrote:  ...    Paraguay adopts permanent -03 starting spring 2024. starting spring *2025* ? Actually, "spring 2024"

[tz] Medovukha factory in Kazakhstan advances its clocks by 1/20 of a day

Last year's move to unify Kazakhstan into a single UTC+05 time zone is seeing some pushback. In "Anger over Kazakh Time Zones" (2024-12-24)[1] RFE/RL's Chris Rickleton and Tasqyn Bolatuly reported that one lawmaker asserted that a majority his party in parliament would support a law to reverse

[tz] Re: Windows compile failure for iana time zones

On 1/13/25 05:17, Manuela Friedrich wrote: It seems that your commit 1ee9daa91818f5d4ab6937352453813fa333e105 fails with: localtime.c(309): error C2099: initializer is not a constant Thanks for reporting that. Which compiler are you using and what version and what compiler flags are you using?

[tz] Re: Paraguay may adopt permanent DST soon

On 1/13/25 13:12, Carlos Raúl Perasso wrote: Is it possible to include Paraguay's change in the next release? Yes, we're planning a release soon, and it'll have the Paraguay change. As far as I know, the only remaining item needing attention before a release is the MSVC issue mentioned on the

[tz] Re: Windows compile failure for iana time zones

Further testing showed that recent patch's use of compound literals also runs afoul of GCC in unusual configurations, and it appears that C23 requires that it use 'constexpr' sometimes but not others. So let's drop that and go to the simpler approach that NetBSD uses. This should also work even

[tz] [PROPOSED] For timestamps compare to HEAD not to index

Problem reported by Bruno Haible in: https://lists.gnu.org/r/bug-gnulib/2024-12/msg00245.html * Makefile (set-timestamps.out): When comparing working file to repository, Use ‘git diff HEAD’ instead of plain ‘git diff’. --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[tz] Re: Windows compile failure for iana time zones

On 2025-01-14 06:29, Brooks Harris via tz wrote: I am currently using MSVC 6.0, circa 1999 OK, but I think Microsoft supports Visual Studio for only ten years and support for MSVC 6.0 ended in 2008[1]. tzcode is intended for current use not computer museums, so typically it shouldn't worry ab

[tz] Chile's Aysén Region might switch from -04/-03 to -03 on April 5

Diario Regional Aysén's Sebastián Martel reports[1] that 94% of Aysén citizens polled in November favored changing the rules from -04/-03-with-DST to -03 all year, and that the wheels have been set in motion to do it. I guess this would affect clocks starting April 5, when Aysén is currently sc

[tz] Re: [tz-announce] 2025a release of tz code and data available

On 2025-01-16 11:21, Geert Hendrickx wrote: On Thu, Jan 16, 2025 at 09:37:50 -0800, Paul Eggert via tz-announce via tz wrote: ...Paraguay adopts permanent -03 starting spring 2024. starting spring *2025* ? Actually, "spring 2024" is correct. Release 2025a says the le

[tz] Re: localized date without time

On 2025-02-11 07:57, Alejandro Colomar wrote: $ date --date='2023-09-20[+0200]' date: invalid date ‘2023-09-20[+0200]’ Does this kind of date-with-timezone look good to you? Would you add support for it in GNU date(1) (via gnulib)? I don't know, it looks a little weird to me. W

[tz] Re: North Dakota HB 1259 requiring year-round standard time

On 2/11/25 07:38, Arthur Olson via tz wrote: A bill has also been introduced in Maryland Similar efforts are present in Utah[1], North Carolina[2], and Maine[3] (for permanent standard time) and in Nebraska[4] (one bill for permanent standard time, one for permanent DST). Most likely there ar

[tz] false story re canceling DST in Canaries and Spain

Last week saw a widely spread false story that daylight saving time will be canceled in Spain and in the Canary Islands, starting in the year 2026. The story was reported as fact in the Daily Mirror[1], which evidently got it from the Canarian Weekly[2]. Both stories said that the last clock ch

[tz] Re: Paraguay Timezone change

On 2025-03-24 10:57, Tim Parenti via tz wrote: We suggest working with the maintainers of these systems to pick up and distribute our latest release to your users. Also, if you have some expertise you can update to the latest release yourself, without waiting for your upstream distributors. Pl

[tz] [PATCH] No need for America/Coyhaique in zonenow.tab

* zonenow.tab (America/Coyhaique): Remove, since it’s the same as America/Sao_Paolo from now on, given today’s change. --- zonenow.tab | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/zonenow.tab b/zonenow.tab index 6aa41678..093f0a0c 100644 --- a/zonenow.tab +++ b/zonenow.ta

[tz] GNU/Linux distros lagging on yesterday's Paraguay change

Most GNU/Linux distributions, Android, iOS, macOS and Microsoft Windows all have at least version 2025a of TZDB, so properly-updated installations should be working correctly after Paraguay's rule change yesterday. However, Repology reports[1] that the latest stable versions of the following GN

[tz] Re: Iran's transition from +04:00 to +03:30 in 1978

On 3/18/25 06:04, Roozbeh Pournader via tz wrote: I hunted down the exact time of Iran's transition from +0400 to +0330. Thanks for doing that. I installed the attached proposed patch to the development repository. It appears that the 1978-11-10 change from +04 to +0330 was at midnight betw

[tz] [PROPOSED] northamerica: mention Daylight Bill

--- northamerica | 9 + 1 file changed, 9 insertions(+) diff --git a/northamerica b/northamerica index 8d356aa0..20b47b48 100644 --- a/northamerica +++ b/northamerica @@ -1611,6 +1611,15 @@ Zone America/Moncton -4:19:08 - LMT 1883 Dec 9 # For more on Orillia, see: Daubs K.

[tz] Re: Paraguay Timezone change

On 3/26/25 08:38, Dale Ghent wrote: Would it make sense to decouple the "political" data of the timezones themselves from the technical tooling? That wouldn't have helped here. Technical tooling (e.g., changes to zic.c or the Makefile) didn't affect our release schedule. And I doubt whether

[tz] Re: SBOM required for tzdata2025b and tzcode2025b

On 2025-04-04 16:50, Guy Harris via tz wrote: The software bills of materials for tzdata2025b and tzcode2025b would be the result of running "tar tf" on the corresponding tarballs (possibly after decompressing if the version of the tar command on your platform doesn't handle gzipped files). S

[tz] Re: Paraguay Timezone change

On 3/25/25 05:22, Carlos Raúl Perasso via tz wrote: The period from the October 2024 development repository update to the January 2025 deployment version, impacting the March rule change, was longer than ideal. I remain a strong advocate for the volunteer efforts that drive our community. Howeve

[tz] Re: Paraguay Timezone change

On 3/25/25 17:07, Jacob Pratt via tz wrote: what is the disadvantage of having more frequent releases? It's more work for downstream distributors, and mistakes are more likely to be released. I tend to worry more about the former than the latter.

[tz] Re: Paraguay Timezone change

On 3/25/25 13:41, Dale Ghent via tz wrote: I think a more realistic strategy would be to make the technical process of implementing timezone adjustments more visible and understandable. It would include a clearer framework for government representatives The current IANA TZDB website doesn't

[tz] Re: DST end time on Lord Howe Island

On 3/27/25 07:28, Heitor David Pinto via tz wrote: However, reading that comment again, my impression is that he was only referring to the start time, not also the end time. Although either interpretation is possible, my impression is the other way, namely, that they always switch at 02:00

[tz] Re: POSIX.1-2024 link in theory.html

Thanks, I thought I'd caught all the old POSIX URLs but evidently not. I installed the attached proposed further patch.From 771a14bf500f8ee8d8ab32e86d19dd3998a343d4 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 1 Apr 2025 15:21:15 -0700 Subject: [PROPOSED] More POSIX link fixes Problems

[tz] [PROPOSED] Cite Neumann & von Blanckenburg’s 2025 DST review

* tz-link.html (Costs and benefits of time shifts): Add citation and brief summary. --- tz-link.html | 8 1 file changed, 8 insertions(+) diff --git a/tz-link.html b/tz-link.html index f4f76fdd..ad2cc972 100644 --- a/tz-link.html +++ b/tz-link.html @@ -985,6 +985,14 @@ a Sleep Research S

[tz] [PROPOSED 2/6] Use reproducible timestamps for *.asc, *.gz, *.lz

When building *.asc, *.gz, and *.lz files for distribution, the files themselves now have reproducible timestamps. Do this by creating new *.t files that have the timestamps for when the other files were created. Formerly, only tarball contents had reproducible timestamps. * Makefile (clean_misc):

[tz] [PROPOSED 3/6] Use correct commit timestamps in tarballs

* Makefile (set-timestamps.out): Use --date=format-local:..., not --date=format:..., because TZ is UTC0 and we want UTC not the committer’s local time. --- Makefile | 2 +- NEWS | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 5b05877c..079bb530

[tz] [PROPOSED 1/6] * Makefile: Modernize comment.

--- Makefile | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 2130582c..502fe2fa 100644 --- a/Makefile +++ b/Makefile @@ -10,10 +10,11 @@ # To affect how this Makefile works, you can run a shell script like this: # # #!/bin/sh -# mak

[tz] [PROPOSED 6/6] Don’t depend on ‘true’ for tzselect

* tzselect.ksh (translit): Use ‘:’, not ‘true’, so as to not depend on having ‘true’. --- tzselect.ksh | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tzselect.ksh b/tzselect.ksh index ca3d82c6..7cd8679d 100644 --- a/tzselect.ksh +++ b/tzselect.ksh @@ -161,15 +161,15 @@ c

[tz] Re: SBOM required for tzdata2025b and tzcode2025b

On 2025-04-05 01:43, Paul Eggert wrote: Perhaps we should add something about SBOMs to theory.html, if only to say something along the lines of the above. After looking into this a bit more, it appears that a good home for this might be the Makefile, as it already talks about POSIX compatibili

[tz] [PROPOSED 4/6] Improve white-space.ck 'make' log

* Makefile (white-space.ck): Use make substitution, not shell substitution, to omit leap-seconds.list. This makes the output of 'make' easier to understand. --- Makefile | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/Makefile b/Makefile index 079bb530..741c730b 100644 --- a

[tz] [PROPOSED 5/6] Don’t depend on grep for tarballs

* Makefile (tzdata$(VERSION)-tailored.tar.gz.t): Use sed, not grep, so that building tarballs no longer depends on having grep; it already depends on sed elsewhere. --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 741c730b..b8029429 100644

[tz] Re: [PATCH] Don't mention boulder.nist.gov

On 2025-04-22 00:28, Martin Burnicki via tz wrote: Right now I can also access this FTP server here from Germany. In the past I was often unable to do that, and sometimes I was unable to access it here from Germany, but succeeded when I tried from a remote server located in the U.S., which see

[tz] opposition to recent time zone change in Paraguay

An article last week in El Nacional reports ongoing public opposition to Paraguay's decision to not fall back on March 22, which means sunrise might not occur until after 07:45 in western Paraguay in June. Sen. Blanca Ovelar will promote going back to the old -04/-03-with-DST regime. Other poss

[tz] Re: wrong last-modified timestamp in NIST leap-seconds.list

On 2025-04-24 07:04, Judah Levine wrote: Your comments have adequately addressed the #$ timetamp definition, which is described in the comments to the file. It has been defined this way for as long as I have prepared the file. There has been no leap second for a long time, and that time s

[tz] Re: [PROPOSED 1/6] * Makefile: Modernize comment.

On 4/21/25 14:06, Magnus Fromreide via tz wrote: +# gettext's internationalion of diagnostics. I suppose internationalion is a typo? Thanks, I installed the attached to fix that.From ff5cbd52d9ef856ef9d0fd589fd726af1bcf3ce8 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 21 Apr 2025 15:

[tz] Re: DST offsets other than +1

On 3/3/25 14:20, Tim Parenti via tz wrote: Not sure if you count grep as a processor Oh, I do: cd /usr/share/zoneinfo for file in $(awk '/^[^#]/{print $3}' zone1970.tab); do echo $file $(tail -n1 $file) done | grep ' [^,]*[0-9],' On Fedora 41 this outputs: Antarctica/Troll <+00>0

[tz] Re: Chile's Aysén Region might switch from -04/-03 to -03 on April 5

Radio Santa María (Coyhaique) reported Wednesday (in Spanish)[1] of a delay in the decision whether Chile’s Aysén Region will switch from -04/-03 (with DST) to all-year -03. A government representative denied that the delay is due to Interior Minister Carolina Tohá’s resignation Tuesday to run

[tz] Re: Paraguay DST is no longer in use

On 2025-03-06 12:51, Brian Inglis via tz wrote: Repology shows 23/46 distros have some release(s) current, Yes, Debian is lagging behind somewhat; I noticed this because the machine I'm typing this email on runs Ubuntu, downstream from Debian. Although TZDB 2025a (released January 15) was ac

[tz] Re: buffer overflow in zic

On 2025-03-05 21:56, Евгений Горбанев wrote: I found this scenario while researching the postgresql code using Svace static analyzer. Well, try this scenario: $ cd /tmp $ wget https://data.iana.org/time-zones/releases/tzdb-2025a.tar.lz $ tar xf tzdb-2025a.tar.lz $ cd tzdb-2025a

[tz] Re: Ireland Time Zone

On 2025-03-11 10:14, Chris Brown via tz wrote: the Eire (GMT+1) and Europe/Dublin (GMT+1) time zones need to be GMT+0, however, they are GMT+1. Are there any standard troubleshooting tips I can pass along to our developers? They can try running this shell command: $ TZ=Europe/Dublin date

[tz] Re: North Dakota HB 1259 requiring year-round standard time

On 2025-02-11 07:09, Andrea Singletary via tz wrote: https://legiscan.com/ND/text/HB1259/2025 ... The tricky thing about this bill is that it does not have an implementation time frame. Although I doubt whether the bill will become law, if it does the state's constitution says it would take e

[tz] Re: buffer overflow in zic

On 2025-03-04 22:12, Evgeniy Gorbanev via tz wrote: Hello! IfoundthatifI runzictocreatea linkonanotherdevice, the bufferoverflowinzip.c:1422inversion2025awill occur. Inthislinei==0. The commandtoreplay: ./zic -l test -d . -t /path/to/ link_on_another_device Best regards, Evgeniy Gorbanyov Un

[tz] Re: EST5EDT should not resolve to America/New_York because they have different offsets

On 2025-02-20 11:01, Jonathan Wakely via tz wrote: That was the offset prior to 1920, but it's -5:00 now. Very minor correction: New York switched to -5:00 on November 18, 1883 at noon new time (17:00 GMT).

[tz] Re: EST5EDT should not resolve to America/New_York because they have different offsets

On 2025-02-20 05:40, Austin Hill via tz wrote: Is this something that you would consider changing? The change to the obsolescent Zone EST5EDT, which made it a link to America/New_York, was intentional and was in response to a bug report by Justin Grant related to JavaScript. See: https://gi

[tz] Re: EST5EDT should not resolve to America/New_York because they have different offsets

On 2025-02-20 11:26, Tom Lane wrote: I take the OP's point to be that if we're keeping it around for System V compatibility, it ought to continue to mean what it meant on System V Unfortunately doing that would cause more trouble than it'd cure, as the System V EST5EDT rules don't match what c

[tz] Re: POSIX.1-2024 link in theory.html

Thanks for reporting that we should be linking to POSIX.1-2024. I installed the attached proposed patches into the development repository.From 656715da3458fbff7e261fe74c46a4ae61a8ca9e Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Fri, 28 Mar 2025 15:15:45 -0700 Subject: [PROPOSED 1/2] Give URL

[tz] Re: Paraguay Timezone change

On 3/26/25 13:40, Dale Ghent via tz wrote: I have two options: And you make good points. However, there is a third option, which I mentioned in [1]. It generates a version number that indicates the "in-between" nature of whatever commit is used and this should mollify (at least to some exten

[tz] [PROPOSED] Don’t mention iso3166.tab in zone1970.tab comment

* zone1970.tab: Remove mention of iso3166.tab in comment. In FreeBSD iso3166.tab is not installed, which makes the comment confusing in an installed file. Although FreeBSD gets around this problem by editing zone1970.tab, it’d be better if FreeBSD could use zone1970.tab unmodified. --- zone1970.t

[tz] Re: Issue with America/Nuuk tz

On 2025-06-18 05:06, Dan Juskevicius via tz wrote: Dear sir or madam, I'm currently working on an issue that one of our customers has reported with the tz database. Using the latest release (2025b), I have been able to reproduce an issue with America/Nuuk time where it reports at -02 instead o

[tz] Re: [EXTERNAL] - Re: Issue with America/Nuuk tz

On 2025-06-19 13:40, Dan Juskevicius wrote: Hi all, I compiled zdump/all related object files for QNX and got identical output to yours: qcc -Vgcc_ntoaarch64le -DUSE_LTZ=0 -lintl -o zdump -O zdump.o localtime.o strftime.o That's to be expected if you use TZDB's localtime.c and strftime.c,

[tz] Re: [EXTERNAL] - Re: Issue with America/Nuuk tz

On 2025-06-20 04:58, Dan Juskevicius wrote: Thanks for the suggestions and support so far. I'll provide an update whenever I figure out the issue. Thank you for reporting the issue. I installed the attached proposed patches to the TZDB man pages to document it. As the second patch indicates

[tz] Re: Should all IDs from backzone be available in backward?

On 2025-06-23 02:51, robertbastian--- via tz wrote: Can Asia/Hanoi be added as a link in backward to ensure compatibility No, because 'backward' is intended to be backward compatibility with older names in the primary files, not for compatibility with something else. I see the confusion the

[tz] Re: TZif Version Selection Issue in tzcode2025b

On 2025-05-30 12:06, PATAN JEELAN BASHA via tz wrote: For example, in the northamerica file, we have: RuleUS 2007max - Mar Sun>=8 2:001:00D RuleUS 2007max - Nov Sun>=1 2:000 S These rules are used by zones such as America

[tz] Re: Should all IDs from backzone be available in backward?

On 2025-07-02 07:24, Lester Caine wrote: The main niggle here is that backzone does contain verified and accurate data prior to the 1970 cut off, and there is no way to access that data other than using backzone? I'm not suggesting removing that data (not all of which is verified and accurate

[tz] Re: Should all IDs from backzone be available in backward?

On 2025-07-01 15:54, Justin Grant via tz wrote: Is there any downside (other than the work required to patch it) to putting this ID into `backward`? Yes, it's not what "backzone" was intended for, and continuing down this path will lead to further grief in the future. The original intent of

[tz] Yucatán thinks of moving from -06 to -05

Yucatán, which corresponds to TZDB’s America/Merida, is considering switching from -06 (CST) all year to -05 (EST) all year.[1] This would be akin to observing permanent daylight saving time. (Yucatán last observed DST in 2022, after which Mexico abolished DST except in regions near the US.) Th

[tz] Re: Annuaire pour l'an ...., publié par le Bureau de Longitudes as a useful source for historical time zone changes

On 2025-07-20 05:53, Gent, R.H. van (Rob) via tz wrote: the French Annuaire pour l'an , publié par le Bureau de Longitudes, published annually since 1797 and available from the Gallica website, usually contains a detailed section on the legal time in France, French colonies and dependencie

[tz] Re: Annuaire pour l'an ...., publié par le Bureau de Longitudes as a useful source for historical time zone changes

On 2025-07-21 00:39, Gent, R.H. van (Rob) wrote: The most recent issue of the Annuaire on Gallica (2021) only lists information for France https://gallica.bnf.fr/ark:/12148/bpt6k9127672b/f52.item (with a sourced list of day light savings from 1916 to 2020) Thanks for the citation. It agre

[tz] Re: Error in the Annuaire du Bureau des Longitudes for 1923

Thanks, I installed the attached proposed further commentary patch.From e03298240e13d30787e671dffd9148e52e9afffd Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 22 Jul 2025 16:41:37 -0700 Subject: [PROPOSED] More commentary about 1923 Paris * europe: Add another comment (thanks to Robert H

[tz] [tz-announce] 2025a release of tz code and data available

The 2025a release of the tz code and data is available. This release contains the following changes: Briefly: Paraguay adopts permanent -03 starting spring 2024. Improve pre-1991 data for the Philippines. Etc/Unknown is now reserved. Changes to future timestamps Paraguay wi

[tz] [tz-announce] 2025b release of tz code and data available

The 2025b release of the tz code and data is available. This release contains the following changes: Briefly: New zone for Aysén Region in Chile which moves from -04/-03 to -03. Changes to future timestamps Chile's Aysén Region moves from -04/-03 to -03 year-round, joining Maga