- tz - lists.iana.org

[PROPOSED] Don’t mention iso3166.tab in zone1970.tab comment
by Paul Eggert May 16, 2025

May 16, 2025

* 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.tab | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/zone1970.tab b/zone1970.tab index 36535bdf..f3227405 100644 --- a/zone1970.tab +++ b/zone1970.tab @@ -2,14 +2,14 @@ # # This file is in the public domain. # -# From Paul Eggert (2018-06-27): +# From Paul Eggert (2025-05-15): # This file contains a table where each row stands for a timezone where # civil timestamps have agreed since 1970. Columns are separated by # a single tab. Lines beginning with '#' are comments. All text uses # UTF-8 encoding. The columns of the table are as follows: # # 1. The countries that overlap the timezone, as a comma-separated list -# of ISO 3166 2-character country codes. See the file 'iso3166.tab'. +# of ISO 3166 2-character country codes. # 2. Latitude and longitude of the timezone's principal location # in ISO 6709 sign-degrees-minutes-seconds format, # either ±DDMM±DDDMM or ±DDMMSS±DDDMMSS, -- 2.49.0

2 1

opposition to recent time zone change in Paraguay
by Paul Eggert May 6, 2025

May 6, 2025

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 possibilities include changing government schedules for schools, banks, etc. to in effect revert the change for some people. Although I do not expect this to affect TZDB in the short run, we should keep an eye on the situation. Nuevo horario divide al Paraguay. El Nacional. 2025-04-29. https://elnacional.com.py/politica/nuevo-horario-divide-paraguay-n84973

1 0

Re: wrong last-modified timestamp in NIST leap-seconds.list
by Paul Eggert April 24, 2025

April 24, 2025

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 stamp reflects that fact. The name of the file is chosen in the same way - it changes only when a new leap event is announced, and now points to a time years ago. > I choose the expiration date of the file so that the list of leap seconds in the file will be correct at least until that date. I use IERS Bulletin C, IERS Bulletin A, and other IERS data to derive that date. It includes a prediction of the evolution of UT1-UTC by the IERS, and is more comprehensive than the simple announcement of a leap second in Bulletin C. > Apart from the recent and continuing drama in the environment here, the file has always been updated long before the expiration date arrives - usually when a new Bulletin C is published. The expiration date is intended to be a safety valve if (and only if) there are more serious problems. I regret that I cannot assure you that the current high level of drama is decreasing. > The leap second file is distributed by FTP. The method has very significant difficulties - it is a long and tedious process to update the file, and there are various reports that it is difficult to access. I don't have a choice about this, at least for now. The other alternatives, such as a web page, would be even more difficult to maintain. Thanks for the heads-up. This makes it clear that the NIST vs IERS leap-seconds.list metadata differences are intentional. I installed the attached proposed patch to TZDB to try to document this in a way that TZDB users can easily understand. If it weren't for the problems with FTP and with NIST's lagging expiration timestamps, I'd prefer the NIST metadata as they're less volatile. For now, though, the proposed patch merely changes commentary, rather than changing the default leap-second data source from the IERS back to the NIST (which was the source for many years, until TZDB release 2024a). Perhaps after things have settled down we can help coordinate the IERS and NIST leap-seconds.list files so that they agree not just about data, but also about the last-modified and expiration timestamps. This would help reduce confusion in the future.

2 1

[PATCH] Don't mention boulder.nist.gov
by Collin Funk April 24, 2025

April 24, 2025

The generated leapseconds file mentions the data can be retrieved from ftp.boulder.nist.gov/pub/time/leap-seconds.list, but the domain no longer resolves. From the Internet Archive for boulder.nist.gov it seems like it was a redirect for nist.gov until it was later deleted. The attached patch removes reference to it. Collin [1] https://web.archive.org/web/20180901000000*/boulder.nist.gov

6 13

[PROPOSED 1/6] * Makefile: Modernize comment.
by Paul Eggert April 21, 2025

April 21, 2025

--- 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 -# make CC='gcc -std=gnu23' "$@" +# make CFLAGS='-O2 -DHAVE_GETTEXT=0' "$@" # -# This example script is appropriate for a circa 2024 GNU/Linux system -# where a non-default setting enables this package's optional use of C23. +# This example script is appropriate for a GNU/Linux system +# which needs more optimization than default, and which does not want +# gettext's internationalion of diagnostics. # # Alternatively, you can simply edit this Makefile to tailor the following # macro definitions. -- 2.48.1

2 7

SBOM required for tzdata2025b and tzcode2025b
by Sahil Sharma D April 21, 2025

April 21, 2025

Hi team, Could you please share the SBOM for tzdata2025b and tzcode2025b? Regards, Sahil

4 6

Iran considering reintroducing daylight saving
by Roozbeh Pournader April 11, 2025

April 11, 2025

There's been news today about Iran potentially reintroducing daylight saving. The CEO of Tavanir, the governmental electric power agency, has said that the government is requesting that the parliament let it set daylight saving at its own pleasure, as opposed to the parliament controlling the rules. He estimates that daylight saving would reduce electricity consumption by about 1%, which could be critical since the country is facing energy shortages.

2 1

POSIX.1-2024 link in theory.html
by Max Nikulin April 1, 2025

April 1, 2025

Hi, I have noticed that <https://data.iana.org/time-zones/theory.html> states > As of this writing, the current edition of POSIX is POSIX.1-2024, which > has been published but not yet in HTML form. It seems, it is time to update this paragraph. For precise location in the repository see the attached file. I am unsure if a more precise link https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap08.html#ta… should be used. Perhaps some other links should be updated to point to the newer standard revision.

2 3

GNU/Linux distros lagging on yesterday's Paraguay change
by Paul Eggert March 27, 2025

March 27, 2025

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 GNU/Linux distributions are still based on TZDB 2024b and thus presumably are misbehaving in Paraguay: Apertis, nixpkgs, OpenWrt, Pardus, Rosa, Trisquel, Ubuntu Of these Ubuntu is best known, and it has several downstream distros that I assume are also affected. So Ubuntu may be the most important laggard for Paraguay. In the list above, I omitted distros like Adélie that use TZDB versions that predate 2024b. I assume these distros are not intended to be up-to-date, are no longer maintained, have distro-specific patches, or aren't tracked accurately by repology. Many other systems also may be out of date for Paraguay; see the first paragraph of the section "The tz database"[2] for a partial list. I haven't tried to track them all. [1]: https://repology.org/project/tzdata/versions [2]: https://data.iana.org/time-zones/tz-link.html#tzdb

3 2

DST end time on Lord Howe Island
by Heitor David Pinto March 27, 2025

March 27, 2025

Hello, In 2001, the database was changed to show the DST start and end times in Lord Howe Island as "2:00" instead of "2:00s". This change only affects the DST end time: if "2:00", it's 2:00 local time, but if "2:00s", it's 2:30 local time. This change was based on a response from the secretary of the island board, who wrote that the DST "changeover" occurred at 2:00 local time. However, reading that comment again, my impression is that he was only referring to the start time, not also the end time. The Standard Time Act of New South Wales says that the summer time period starts and ends at 2:00, but at least in the mainland of New South Wales this is interpreted as 2:00 standard time, so I believe that it should be so for Lord Howe Island as well. All other Australian locations in the database show "2:00s". https://legislation.nsw.gov.au/view/whole/html/inforce/current/act-1987-149 Whether the DST end time is 2:00 or 2:30 local time probably has no practical consequence, as at that time everything is closed on the island and people are asleep. But for precision, I think that it would be useful to confirm this with someone on the island again. Regards, David

2 1