- tz - lists.iana.org

Kazakhstan (all parts) switching to UTC+5 on March 1, 2024
by Zhanbolat Raimbekov Jan. 21, 2024

Jan. 21, 2024

Kazakhstan (all parts) switching to UTC+5 on March 1, 2024 https://www.gov.kz/memleket/entities/mti/press/news/details/688998?lang=ru

5 9

[PATCH] Asia/Ho_Chi_Minh: Correct 1955 transition
by Đoàn Trần Công Danh Jan. 20, 2024

Jan. 20, 2024

While we're at it, updating source for 1959 transition. Ordinance 46 of 1955, first article read: Kể từ ngày mồng 1 tháng bảy năm 1955, giờ chính-thức ở Việt-nam là giờ của thời đạo thứ bảy. >From the 1955-07-01, the offical time in Vietnam is the time of the +07 timezone. ... lùi chậm sáu mươi phút, trong đêm hôm 30 tháng sáu năm 1955, rạng mặt ngày mồng 1 tháng bảy năm 1955 lúc một giờ sáng. ... move back 60 minutes, in the night of 1955-06-30, early morning of 1955-07-01 at 1AM. Decree 362-TTP of 1959, first article read: Kể từ ngày mồng 1 tháng giêng d.l. năm 1960, giờ chánh thức và pháp định ở Việt-nam được đặt nhanh hơn giờ của thời-đạo thứ bảy sáu mươi phút. >From the 1st of January 1960, de facto and de jure time in Vietnam will be faster than the +07 timezone, 60 minutes. ... vặn nhanh lên sáu mươi phút lúc 23 giờ đêm hôm 31 tháng chạp d.l. năm 1959, rạng mặt ngày mồng 1 tháng giêng d.l. năm 1960. ... fast forward 60 minutes at 23:00 of the night of 1959-12-31, early morning of 1960-01-01. --- NEWS | 3 +++ asia | 14 +++++++++++++- 2 files changed, 16 insertions(+), 1 deletion(-) diff --git a/NEWS b/NEWS index 653512fa..705a2985 100644 --- a/NEWS +++ b/NEWS @@ -8,6 +8,9 @@ Unreleased, experimental changes Changes to past timestamps + In 1955, Asia/Ho_Chi_Minh's transitions occurred at 01:00 the + next day. (Reported by Đoàn Trần Công Danh.) + From 1947 through 1949, Toronto's transitions occurred at 02:00 not 00:00. (Thanks to Chris Walton.) diff --git a/asia b/asia index 8028c06e..db0c90e3 100644 --- a/asia +++ b/asia @@ -4088,6 +4088,18 @@ Zone Asia/Tashkent 4:37:11 - LMT 1924 May 2 # It also mentions a 1945-03-29 decree (by a Japanese Goveror-General) # to set the time zone to +09, but does not say whether that decree # merely legalized an earlier change to +09. +# +# July 1955 transition: +# Ngô Đình Diệm, Công Báo Việt Nam, No. 92 (1955-07-02), page 1780-1781 +# Ordinance (Dụ) No. 46 (1955-06-25) +# http://ddsnext.crl.edu/titles/32341#?c=0&m=29&s=0&cv=4&r=0&xywh=-89%2C342%2… +# It says that on 1955-07-01 at 01:00, South Vietnam moved back 1 hour (to +07). +# +# December 1959 transition: +# Ngô Đình Diệm, Công Báo Việt Nam Cộng Hòa, 1960 part 1 (1960-01-02), page 62 +# Decree (Sắc lệnh) No. 362-TTP (1959-12-30) +# http://ddsnext.crl.edu/titles/32341#?c=0&m=138&s=0&cv=793&r=0&xywh=-54%2C15… +# It says that on 1959-12-31 at 23:00, South Vietnam moved forward 1 hour (to +08). # Zone NAME STDOFF RULES FORMAT [UNTIL] @@ -4098,7 +4110,7 @@ Zone Asia/Ho_Chi_Minh 7:06:30 - LMT 1906 Jul 1 8:00 - +08 1945 Mar 14 23:00 9:00 - +09 1945 Sep 1 24:00 7:00 - +07 1947 Apr 1 - 8:00 - +08 1955 Jul 1 + 8:00 - +08 1955 Jul 1 01:00 7:00 - +07 1959 Dec 31 23:00 8:00 - +08 1975 Jun 13 7:00 - +07 -- 2.43.0.422.g5e73029237

2 1

Fwd: Dave Mills has passed away
by Marshall Eubanks Jan. 19, 2024

Jan. 19, 2024

Sad news. ---------- Forwarded message --------- From: Lars Eggert <lars(a)eggert.org> Date: Fri, Jan 19, 2024 at 12:12 PM Subject: Fwd: Dave Mills has passed away To: <ietf(a)ietf.org> Sad news. -- Sent from a mobile device; please excuse typos. Begin forwarded message: From: vinton cerf <vgcerf(a)gmail.com> Date: January 19, 2024 at 03:39:37 GMT+2 To: Andrew Sullivan <sullivan(a)isoc.org> Cc: Warren Kumari <warren(a)kumari.net>, John C Klensin <klensin(a)jck.com>, Hans-Werner Braun <hwb(a)ucsd.edu>, Dan Lynch <dan(a)lynch.com>, Stephen Kent <stkent(a)verizon.net> Subject: Dave Mills has passed away Please relay to IAB, IETF, IRTF and Hall of Fame His daughter, Leigh, just sent me the news that Dave passed away peacefully on January 17, 2024. He was such an iconic element of the early Internet. Network Time Protocol, the Fuzzball routers of the early NSFNET, INARG taskforce lead, COMSAT Labs and University of Delaware and so much more. vint

1 0

Kazakhstan (all parts) switching to UTC+5 on March 1, 2024 (officially accepted the law)
by Zhanbolat Raimbekov Jan. 19, 2024

Jan. 19, 2024

Kazakhstan (all states/oblasts) switching to UTC+5 on March 1, 2024 at 00:00 Currently, Kazakhstan has two time zones +5 and +6. +6 will switch to +5 on March 1, 2024 at midnight. https://www.gov.kz/memleket/entities/mti/press/news/details/688998?lang=ru (Updated 19 Jan, 2024) -- Zhanbolat Raimbekov

1 0

Kazakhstan to switch to a single time zone on March 1, 2024
by wtz＠worldtimezone.com Jan. 19, 2024

Jan. 19, 2024

According to a different news and the official web site for the Ministry of Trade and Integration of the Republic of Kazakhstan: https://en.inform.kz/news/kazakhstan-to-switch-to-single-hour-zone-mar-1-54… https://akipress.com/news:755336:Single_time_zone_to_be_set_in_Kazakhstan_f… Official web site for the Ministry of Trade and Integration of the Republic of Kazakhstan Kazakhstan to switch to a single time zone (updated text in Russian as of Jan 19, 2024) https://www.gov.kz/memleket/entities/mti/press/news/details/688998?lang=ru [1] (Dec 14, 2023 Press center / Media) https://en.inform.kz/news/kazakhstan-to-switch-to-single-hour-zone-mar-1-54… Single Time Zone in Kazakhstan: A working group of scientists met with public activists in East Kazakhstan Oblast https://www.gov.kz/memleket/entities/mti/press/media/details/42218?lang=en and our link on https://www.worldtimezone.com/dst_news/dst_news_kazakhstan01.html Kazakhstan will switch to the single time zone at 00:00 on March 1, 2024, to introduce the UTC+05.00 time throughout the country, Kazinform News Agency reports. According to the decree as of November 23, 2000, the akimats of Astana, Almaty and Shymkent cities, as well as Akmola, Almaty, Zhambyl, Karaganda, Kostanay, Pavlodar, North Kazakhstan, Turkistan, East Kazakhstan, Abai, Zhetysu, and Ulytau regions, have to turn the clock back an hour in the night of February 29th to March 1st at 00.00. As of today, there are two time zones in Kazakhstan UTC+5 and UTC+6. Regards, Alexander Krivenyshev, WorldTimeZone.com Links: ------ [1] https://www.gov.kz/memleket/entities/mti/press/news/details/688998?lang=ru

1 0

Kazakhstan time zone changes on Feb. 29th
by Ivan Ryzhov Jan. 19, 2024

Jan. 19, 2024

1 0

Kazakhstan switches to UTC+5
by Pavel Starosek Jan. 19, 2024

Jan. 19, 2024

Hello, Today government agencies announced a change in time zone from UTC+6 to UTC+5 from 00:00 on March 1, 2024. After this Kazakhstan will have a single time zone. https://www.gov.kz/memleket/entities/mti/press/news/details/688998?lang=ru > Amendments have been made to the Government Decree “On the procedure for calculating time on the territory of the Republic of Kazakhstan”. According to the changes, the use of a single time zone throughout the country is established from 00:00 on March 1, 2024. > Thus, the 5th time zone (UTC+5) will be applied to the entire territory of the Republic of Kazakhstan. > Today in Kazakhstan there are two time zones UTC+5 and UTC+6. Most of the country's territory (with the exception of the western regions) is located in the UTC+6 zone. > The resolution is subject to official publication and comes into force on March 1, 2024. -- Thanks, Pavel Starosek

1 0

Canadian Geographic Matthews & Vincent article URI updates
by Brian Inglis Jan. 17, 2024

Jan. 17, 2024

Current tzdata contains northamerica:1413: # From Paul Eggert (2014-10-18): # H. David Matthews and Mary Vincent's map # "It's about TIME", _Canadian Geographic_ (September-October 1998) # http://www.canadiangeographic.ca/Magazine/SO98/alacarte.asp # contains detailed boundaries for regions observing nonstandard # time and daylight saving time arrangements in Canada circa 1998. Could update this with the Archive.org URIs below or possibly move it to tz-art.html section "Books, plays and magazines": H. David Matthews and Mary Vincent, earliest working Archive.org URIs: https://web.archive.org/web/20071217083933/http://www.canadiangeographic.ca… https://web.archive.org/web/19990827055050/https://canadiangeographic.ca/SO… "It's about TIME", "À la Carte" column, Canadian Geographic Magazine, September/October 1998 issue; original CanGeog URIs: http://www.canadiangeographic.ca/Magazine/SO98/alacarte.asp https://canadiangeographic.ca/SO98/geomap.htm Summarizes Canada's time zone rules, boundaries, deviations, and exceptions with maps. In each pair of URIs for Archive.org and CanGeog original, the 1st URI is for article content within that issue's column context, the 2nd URI is the article content alone. -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry

3 3

[PROPOSED] Draft next POSIX has tm_gmtoff, tm_zone
by Paul Eggert Jan. 14, 2024

Jan. 14, 2024

* private.h (TM_GMTOFF, TM_ZONE): Treat draft next POSIX like glibc etc., since it requires tm_gmtoff and tm_zone. --- private.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/private.h b/private.h index 07316289..8eff90b7 100644 --- a/private.h +++ b/private.h @@ -768,7 +768,8 @@ time_t posix2time(time_t); /* Infer TM_ZONE on systems where this information is known, but suppress guessing if NO_TM_ZONE is defined. Similarly for TM_GMTOFF. */ -#if (defined __GLIBC__ \ +#if (200809 < _POSIX_VERSION \ + || defined __GLIBC__ \ || defined __tm_zone /* musl */ \ || defined __FreeBSD__ || defined __NetBSD__ || defined __OpenBSD__ \ || (defined __APPLE__ && defined __MACH__)) -- 2.40.1

2 4

[PATCH] Asia/Ho_Chi_Minh 1945-09 Source added
by Đoàn Trần Công Danh Jan. 14, 2024

Jan. 14, 2024

A new source for the transition of Asia/Ho_Chi_Minh and Asia/Hanoi from +09 to +07 was found. The source is Việt Nam Dân Quốc Công Báo (Official Journal of the People Republic of Viet Nam). Original text and translation: Bộ-trưởng bộ Nội-vụ Minister of Ministry of Internal Affairs Chiểu chi nghị-định cựu Toàn-Quyền Đông-Dương ngày 29 tháng 3 năm 1945 ấn định giờ chính thức ở Đông-Dương, Based on the decision of the former Governor-General of the (French) Indochina on the 29th of March, 1945, that dictated the official timezone in Indochina, Nghị-Định Decided Điều thứ nhất: Trong toàn cõi nước Việt-Nam, giờ chính thức do nghị định ngày 29 tháng 3 năm 1945 ấn định, sẽ lui lại hai giờ, kể từ 24 giờ, ngày mồng 1 tháng 9 năm 1945. Article 1: In the whole Viet-Nam, the official timezone as dictated by decision on the 29th of March 1945, would move back 2 hours, effective at 24:00 on the 1st of September 1945 Điều thứ hai: Nghị-định cựu Toàn-Quyền Đông-Dương ngày 29 tháng 3 năm 1945 kể trên từ nay sẽ bãi bỏ. Article 2: The Decision on the 29 of March 1945 of the former Governor-General of the Indochina would be canceled from now on. Hà-nội ngày mồng 1 tháng 9 năm 1945 --- asia | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/asia b/asia index 04526c19..e8317127 100644 --- a/asia +++ b/asia @@ -4058,6 +4058,15 @@ Zone Asia/Tashkent 4:37:11 - LMT 1924 May 2 # which is used below even though the modern-day Phù Liễn Observatory # is closer to 07:06:31. Abbreviate Phù Liễn Mean Time as PLMT. # +# In September 1, 1945, Vietnam moved back 2 hours, back to GMT+7. +# In that very decision, they mentioned an old decision to change timezone +# in March 29, 1945. It's unknown whether Vietnam moved to GMT+9 either on +# or after March 29, 1945; or the decision (by a Japanese Goveror-General) +# only legalised the change to GMT+9 earlier. +# Source: Việt Nam Dân Quốc Công Báo, No. 1, September 29, 1945 +# Archived by National Library of Viet Nam +# http://baochi.nlv.gov.vn/baochi/cgi-bin/baochi?a=d&d=JwvzO19450929.2.5&srpo… +# # The following transitions occurred in Indochina in general (before 1954) # and in South Vietnam in particular (after 1954): # To 07:00 on 1911-05-01. -- 2.43.0.422.g5e73029237

2 1

Extra transition for Europe/London with 2023d
by Derick Rethans Jan. 14, 2024

Jan. 14, 2024

Hi, I have just updated the tzdb for PHP, and one of our tests started failing, and it turned out due to an unexpected data change: Previously, the following transitions existed: … 1994-03-27 01:00:00 UT ( 764730000) = 1 [ 3600 1 4 'BST' (0,0)] 1994-10-23 01:00:00 UT ( 782874000) = 2 [ 0 0 8 'GMT' (0,0)] 1995-03-26 01:00:00 UT ( 796179600) = 1 [ 3600 1 4 'BST' (0,0)] 1995-10-22 01:00:00 UT ( 814323600) = 2 [ 0 0 8 'GMT' (0,0)] 1996-03-31 01:00:00 UT ( 828234000) = 1 [ 3600 1 4 'BST' (0,0)] POSIX string: GMT0BST,M3.5.0/1,M10.5.0 std: 2 [ 0 0 8 'GMT' (0,0)] dst: 1 [ 3600 1 4 'BST' (0,0)] But now, they include an extra one for Jan 1st, 1996, with the March 31st one now not being the last one: … 1994-03-27 01:00:00 UT ( 764730000) = 1 [ 3600 1 4 'BST' (0,0)] 1994-10-23 01:00:00 UT ( 782874000) = 2 [ 0 0 8 'GMT' (0,0)] 1995-03-26 01:00:00 UT ( 796179600) = 1 [ 3600 1 4 'BST' (0,0)] 1995-10-22 01:00:00 UT ( 814323600) = 2 [ 0 0 8 'GMT' (0,0)] 1996-01-01 00:00:00 UT ( 820454400) = 2 [ 0 0 8 'GMT' (0,0)] POSIX string: GMT0BST,M3.5.0/1,M10.5.0 std: 2 [ 0 0 8 'GMT' (0,0)] dst: 1 [ 3600 1 4 'BST' (0,0)] I couldn't find anywhere in tzfile.5 or theory.html whether the last generated transition must match a transition as specified with the POSIX string (as it did with 2023c and earlier), but I vaguely remember having read such a thing when I implemented the POSIX string parsing logic. As far as I know so-far, the only effect it has on PHP users is that they will now see an extra transition when they enumerate them (the 1996-01-01 is inserted). I think I am mostly flagging this up because this was an unexpected change. cheers, Derick -- https://derickrethans.nl | https://xdebug.org | https://dram.io Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support Host of PHP Internals News: https://phpinternals.news mastodon: @derickr@phpc.social @xdebug@phpc.social twitter: @derickr and @xdebug

16 66

[PROPOSED] "m" now abbreviates both "maximum" and "minimum"
by Paul Eggert Jan. 11, 2024

Jan. 11, 2024

* zishrink.awk: Add comment about "m". --- zishrink.awk | 3 +++ 1 file changed, 3 insertions(+) diff --git a/zishrink.awk b/zishrink.awk index 66968e86..eb4aa785 100644 --- a/zishrink.awk +++ b/zishrink.awk @@ -199,6 +199,9 @@ function process_input_line(line, \ } # Abbreviate "max", "min", "only" and month names. + # Although "max" and "min" can both be abbreviated to just "m", + # use the longer forms "ma" and "mi" for now, + # for compatibility with zic 2023d and earlier. gsub(/ max /, " ma ", line) gsub(/ min /, " mi ", line) gsub(/ only /, " o ", line) -- 2.40.1

2 2

NIST URLs for leap-seconds.list in leapseconds.awk
by PoolMUC＠web.de Jan. 10, 2024

Jan. 10, 2024

3 2

Ontario 1949-1950 DST->STD in Sep not Nov
by Brian Inglis Jan. 10, 2024

Jan. 10, 2024

I noticed changes in the DST->STD transition dates to the follwing week mentioned in an Alexandria, Ontario weekly newspaper article linked from a page on an unrelated issue, and checking that against zdump found that 1949 & 1950 appear to have transitioned in November, rather than September as in other years from 1946-1956, which from comments in northamerica, appear to derive from Shanks & Pottenger. So I also downloaded the same paper's issue from the same week of September in the other questionable year, and found another article announcing the change that weekend. As well as time being the lede in top of front page articles about municipal business, there are also municipal notices of time changes in later pages, as well as Canadian National railway ads announcing updated time tables being available from that weekend, and an article listing updated CNR train times from Montreal, and a mention of a follow up when Montreal time changes the weekend following Ontario cities. The attached files show relevant edited pdftotext extracts from the PDFs. Note that the municipality changed its time a day leter than elsewhere in Ontario, midnight Sunday/Monday rather than Saturday/Sunday, so that people will not miss Sunday church services, but Monday work does not matter! [Canada traditionally calls the prairie provinces the "Bible Belt" and there are visible signs of that, including dry municipalities where alcohol was not available, but that did not stop many bars and shops in nearby towns opening Sundays, if there was enough business to be worth it, whereas many eastern provinces had legal restrictions on stores and bars opening on Sundays until recently.]

3 5

trailing whitespace in IERS leap-seconds.list file
by Paul Eggert Jan. 10, 2024

Jan. 10, 2024

Martin Burnicki writes that the IERS's current leap-seconds.list file has a notice that it's in the public domain. Thanks: this means there's no copyright issue in including a copy of the file in the Time Zone Database (TZDB). While testing that, though, I got the following warning from our version control system: .git/rebase-apply/patch:284: trailing whitespace. # Since the adoption of this system in 1972 it has been necessary to add a number of seconds to UTC, warning: 1 line adds whitespace errors. This warning occurs because line 21 of <https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list> contains a trailing space character. Could you please remove it? That will lessen aggravation downstream. Thanks.

3 4

[PROPOSED] Miquelon 1911 transition was June 15 not May 15
by Paul Eggert Jan. 10, 2024

Jan. 10, 2024

I found a new source: Société Française de Physique, Recueil de constantes physiques (1913), page 752 (errata and addenda), 18b. It agrees with Shanks about the adoption of standard time in French possessions, except for Miquelon. Prefer it to Shanks. Also, fill in day of month (e.g., “Jan 1” not “Jan”) for other transitions, since the source seems careful about the day. * NEWS: Mention this. * africa (Africa/Ndjamena, Africa/Abidjan): * australasia (Pacific/Gambier, Pacific/Marquesas, Pacific/Tahiti) (Pacific/Guadalcanal): * northamerica (America/Martinique): * southamerica (America/Cayenne): Fill in day of month as 1. This does not change the transitions; it’s merely documentation. * northamerica (America/Miquelon): 1911 transition was Jun 15, not May 15. --- NEWS | 2 ++ africa | 8 ++++++-- australasia | 12 ++++++++---- northamerica | 8 ++++++-- southamerica | 5 ++++- 5 files changed, 26 insertions(+), 9 deletions(-) diff --git a/NEWS b/NEWS index 6dba3dfb..f0ccfa87 100644 --- a/NEWS +++ b/NEWS @@ -11,6 +11,8 @@ Unreleased, experimental changes From 1947 through 1949, Toronto's transitions occurred at 02:00 not 00:00. (Thanks to Chris Walton.) + In 1911 Miquelon adopted standard time on June 15, not May 15. + Changes to code The FROM and TO columns of Rule lines can no longer be "minimum" diff --git a/africa b/africa index 6fae18c0..92d823a0 100644 --- a/africa +++ b/africa @@ -30,6 +30,10 @@ # Milne J. Civil time. Geogr J. 1899 Feb;13(2):173-94. # https://www.jstor.org/stable/1774359 # +# For the 1911/1912 establishment of standard time in French possessions, see: +# Société Française de Physique, Recueil de constantes physiques (1913), +# page 752, 18b. +# # European-style abbreviations are commonly used along the Mediterranean. # For sub-Saharan Africa abbreviations were less standardized. # Previous editions of this database used WAT, CAT, SAT, and EAT @@ -113,7 +117,7 @@ Zone Atlantic/Cape_Verde -1:34:04 - LMT 1912 Jan 01 2:00u # Praia # Chad # Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Africa/Ndjamena 1:00:12 - LMT 1912 # N'Djamena +Zone Africa/Ndjamena 1:00:12 - LMT 1912 Jan 1 # N'Djamena 1:00 - WAT 1979 Oct 14 1:00 1:00 WAST 1980 Mar 8 1:00 - WAT @@ -139,7 +143,7 @@ Zone Africa/Ndjamena 1:00:12 - LMT 1912 # N'Djamena # Inaccessible, Nightingale: uninhabited # Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Africa/Abidjan -0:16:08 - LMT 1912 +Zone Africa/Abidjan -0:16:08 - LMT 1912 Jan 1 0:00 - GMT ############################################################################### diff --git a/australasia b/australasia index dc98c1e2..a9e9eb4a 100644 --- a/australasia +++ b/australasia @@ -420,11 +420,11 @@ Zone Pacific/Fiji 11:55:44 - LMT 1915 Oct 26 # Suva # French Polynesia # Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Pacific/Gambier -8:59:48 - LMT 1912 Oct # Rikitea +Zone Pacific/Gambier -8:59:48 - LMT 1912 Oct 1 # Rikitea -9:00 - -09 -Zone Pacific/Marquesas -9:18:00 - LMT 1912 Oct +Zone Pacific/Marquesas -9:18:00 - LMT 1912 Oct 1 -9:30 - -0930 -Zone Pacific/Tahiti -9:58:16 - LMT 1912 Oct # Papeete +Zone Pacific/Tahiti -9:58:16 - LMT 1912 Oct 1 # Papeete -10:00 - -10 # Clipperton (near North America) is administered from French Polynesia; # it is uninhabited. @@ -802,7 +802,7 @@ Zone Pacific/Apia 12:33:04 - LMT 1892 Jul 5 # Solomon Is # excludes Bougainville, for which see Papua New Guinea # Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone Pacific/Guadalcanal 10:39:48 - LMT 1912 Oct # Honiara +Zone Pacific/Guadalcanal 10:39:48 - LMT 1912 Oct 1 # Honiara 11:00 - +11 # Tokelau @@ -963,6 +963,10 @@ Zone Pacific/Efate 11:13:16 - LMT 1912 Jan 13 # Vila # Milne J. Civil time. Geogr J. 1899 Feb;13(2):173-94. # https://www.jstor.org/stable/1774359 # +# For the 1911/1912 establishment of standard time in French possessions, see: +# Société Française de Physique, Recueil de constantes physiques (1913), +# page 752, 18b. +# # A reliable and entertaining source about time zones is # Derek Howse, Greenwich time and longitude, Philip Wilson Publishers (1997). # diff --git a/northamerica b/northamerica index 44fd50bd..0163d17a 100644 --- a/northamerica +++ b/northamerica @@ -1268,6 +1268,10 @@ Zone America/Menominee -5:50:27 - LMT 1885 Sep 18 12:00 # <http://cs.ucla.edu/~eggert/The-Waste-of-Daylight-19th.pdf> # [PDF] (1914-03) # +# For the 1911/1912 establishment of standard time in French possessions, see: +# Société Française de Physique, Recueil de constantes physiques (1913), +# page 752, 18b. +# # See the 'europe' file for Greenland. # Canada @@ -3437,7 +3441,7 @@ Zone America/Jamaica -5:07:10 - LMT 1890 # Kingston # Martinique # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone America/Martinique -4:04:20 - LMT 1890 # Fort-de-France - -4:04:20 - FFMT 1911 May # Fort-de-France MT + -4:04:20 - FFMT 1911 May 1 # Fort-de-France MT -4:00 - AST 1980 Apr 6 -4:00 1:00 ADT 1980 Sep 28 -4:00 - AST @@ -3544,7 +3548,7 @@ Zone America/Puerto_Rico -4:24:25 - LMT 1899 Mar 28 12:00 # San Juan # St Pierre and Miquelon # There are too many St Pierres elsewhere, so we'll use 'Miquelon'. # Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone America/Miquelon -3:44:40 - LMT 1911 May 15 # St Pierre +Zone America/Miquelon -3:44:40 - LMT 1911 Jun 15 # St Pierre -4:00 - AST 1980 May -3:00 - -03 1987 -3:00 Canada -03/-02 diff --git a/southamerica b/southamerica index 19c7e456..344e67f3 100644 --- a/southamerica +++ b/southamerica @@ -1570,8 +1570,11 @@ Zone Atlantic/Stanley -3:51:24 - LMT 1890 -3:00 - -03 # French Guiana +# For the 1911/1912 establishment of standard time in French possessions, see: +# Société Française de Physique, Recueil de constantes physiques (1913), +# page 752, 18b. # Zone NAME STDOFF RULES FORMAT [UNTIL] -Zone America/Cayenne -3:29:20 - LMT 1911 Jul +Zone America/Cayenne -3:29:20 - LMT 1911 Jul 1 -4:00 - -04 1967 Oct -3:00 - -03 -- 2.40.1

1 0

NIST URLs for leap-seconds.list in leapseconds.awk
by PoolMUC＠web.de Jan. 10, 2024

Jan. 10, 2024

(apologies for earlier HTML mail, same message again in plain text (hopefully...)) Hi, After recent updates to leapseconds.awk to include IERS as a source for leap-seconds.list, one URL given for the file at NIST still is ftp://ftp.nist.gov/pub/time/leap-seconds.list: print "# This file is generated automatically from the data in the public-domain" print "# NIST/IERS format leap-seconds.list file, which can be copied from" print "# <https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list>" print "# or, in a variant with different comments, from" print "# <ftp://ftp.nist.gov/pub/time/leap-seconds.list>" print "# or <ftp://ftp.boulder.nist.gov/pub/time/leap-seconds.list>." However, at least for me, and at this time, the hostname ftp.nist.gov does not resolve. ftp.boulder.nist.gov does resolve. If others are seeing the same, and the condition persists, maybe the URL based on ftp.nist.gov should be removed. Thanks!

1 0

Fwd: Bulletin C number 67
by Martin Burnicki Jan. 9, 2024

Jan. 9, 2024

Bulletin C number 67 is available, see also: https://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat At the same time, a new NTP leap second file has been made available by IERS (directory listing): https://hpiers.obspm.fr/iers/bul/bulc/ntp/ New file: https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.3913697179 As expected, no leap second is scheduled for the end of June 2024, but the expiration date of the file has been updated. As far as I see, the file also includes the changes recently discussed on this list, regarding a copyright info and some cosmetic changes. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki(a)meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Natalie Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com

2 1

2023d zdump with "min" year rule?
by Yoshito Umaoka Jan. 8, 2024

Jan. 8, 2024

Dear TZ Database maintainers, We (Unicode ICU project) preserve time zones deprecated in the TZ database. We keep old systemv file and include these zones in our library. For example, # SystemV time zones. # IANA tzdb file 'systemv' file has these SystemV/* zones commented out up to 2020a. # 'systemv' file was removed in 2020b. We keep them in this supplemental zone data # file for compatibility purpose. # Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S Rule SystemV min 1973 - Apr lastSun 2:00 1:00 D Rule SystemV min 1973 - Oct lastSun 2:00 0 S Rule SystemV 1974 only - Jan 6 2:00 1:00 D Rule SystemV 1974 only - Nov lastSun 2:00 0 S Rule SystemV 1975 only - Feb 23 2:00 1:00 D Rule SystemV 1975 only - Oct lastSun 2:00 0 S Rule SystemV 1976 max - Apr lastSun 2:00 1:00 D Rule SystemV 1976 max - Oct lastSun 2:00 0 S # Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL] Zone SystemV/AST4ADT -4:00 SystemV A%sT Zone SystemV/EST5EDT -5:00 SystemV E%sT Zone SystemV/CST6CDT -6:00 SystemV C%sT Zone SystemV/MST7MDT -7:00 SystemV M%sT Zone SystemV/PST8PDT -8:00 SystemV P%sT Zone SystemV/YST9YDT -9:00 SystemV Y%sT Zone SystemV/AST4 -4:00 - AST Zone SystemV/EST5 -5:00 - EST Zone SystemV/CST6 -6:00 - CST Zone SystemV/MST7 -7:00 - MST Zone SystemV/PST8 -8:00 - PST Zone SystemV/YST9 -9:00 - YST Zone SystemV/HST10 -10:00 - HST ICU data build feeds the extra zone file including above to zic, then run zdump to emit zone offset transitions. Then compare the output with the equivalent output produced by ICU library code. I’m currently working on TZ database 2023d and found this check is failing for SystemV/* with daylight saving time rule. All other zones work fine. With zdump in 2023d, all transitions before 1970 are not reported. For example: $ zdump -c 1900,1975 -V SystemV/AST4ADT emits the output below: SystemV/AST4ADT Sun Apr 26 05:59:59 1970 UT = Sun Apr 26 01:59:59 1970 AST isdst=0 gmtoff=-14400 SystemV/AST4ADT Sun Apr 26 06:00:00 1970 UT = Sun Apr 26 03:00:00 1970 ADT isdst=1 gmtoff=-10800 SystemV/AST4ADT Sun Oct 25 04:59:59 1970 UT = Sun Oct 25 01:59:59 1970 ADT isdst=1 gmtoff=-10800 SystemV/AST4ADT Sun Oct 25 05:00:00 1970 UT = Sun Oct 25 01:00:00 1970 AST isdst=0 gmtoff=-14400 SystemV/AST4ADT Sun Apr 25 05:59:59 1971 UT = Sun Apr 25 01:59:59 1971 AST isdst=0 gmtoff=-14400 SystemV/AST4ADT Sun Apr 25 06:00:00 1971 UT = Sun Apr 25 03:00:00 1971 ADT isdst=1 gmtoff=-10800 SystemV/AST4ADT Sun Oct 31 04:59:59 1971 UT = Sun Oct 31 01:59:59 1971 ADT isdst=1 gmtoff=-10800 SystemV/AST4ADT Sun Oct 31 05:00:00 1971 UT = Sun Oct 31 01:00:00 1971 AST isdst=0 gmtoff=-14400 SystemV/AST4ADT Sun Apr 30 05:59:59 1972 UT = Sun Apr 30 01:59:59 1972 AST isdst=0 gmtoff=-14400 SystemV/AST4ADT Sun Apr 30 06:00:00 1972 UT = Sun Apr 30 03:00:00 1972 ADT isdst=1 gmtoff=-10800 SystemV/AST4ADT Sun Oct 29 04:59:59 1972 UT = Sun Oct 29 01:59:59 1972 ADT isdst=1 gmtoff=-10800 SystemV/AST4ADT Sun Oct 29 05:00:00 1972 UT = Sun Oct 29 01:00:00 1972 AST isdst=0 gmtoff=-14400 SystemV/AST4ADT Sun Apr 29 05:59:59 1973 UT = Sun Apr 29 01:59:59 1973 AST isdst=0 gmtoff=-14400 SystemV/AST4ADT Sun Apr 29 06:00:00 1973 UT = Sun Apr 29 03:00:00 1973 ADT isdst=1 gmtoff=-10800 SystemV/AST4ADT Sun Oct 28 04:59:59 1973 UT = Sun Oct 28 01:59:59 1973 ADT isdst=1 gmtoff=-10800 SystemV/AST4ADT Sun Oct 28 05:00:00 1973 UT = Sun Oct 28 01:00:00 1973 AST isdst=0 gmtoff=-14400 SystemV/AST4ADT Sun Jan 6 05:59:59 1974 UT = Sun Jan 6 01:59:59 1974 AST isdst=0 gmtoff=-14400 SystemV/AST4ADT Sun Jan 6 06:00:00 1974 UT = Sun Jan 6 03:00:00 1974 ADT isdst=1 gmtoff=-10800 SystemV/AST4ADT Sun Nov 24 04:59:59 1974 UT = Sun Nov 24 01:59:59 1974 ADT isdst=1 gmtoff=-10800 SystemV/AST4ADT Sun Nov 24 05:00:00 1974 UT = Sun Nov 24 01:00:00 1974 AST isdst=0 gmtoff=-14400 This is not a problem with 2023c. 2023c emits transitions starting year 1900 (the first year in the range) to 1975. I think these are only zones using rule line with “min” year rule. I suspect there is a regression bug in zdump when such rule is used. -Yoshito Umaoka

2 2

Ministry of Digital Development and Communications, the Government of Mongolia
by fr Jan. 7, 2024

Jan. 7, 2024

Dear Sir/Ma'am, As we sent an inquiry regarding the switching time to the regular summer time matter earlier, could you please provide us some recommendations on below. The Government of Mongolia is planning to switch to the regular summer time from 22-26 March, 2024. Currently, the discussions are made within the Government as well as at the Parliament. We expect that final decision will be made in the October. Therefore, is it possible to arrange the switching process in the next 5 months? Is there any extraordinary cases like us or not? Or shall we make our changes in the September 2024? Thank you for your kind consideration in advance and hope to hear from you soon. Sincerely, Ms. Ariuntuul --- Foreign Cooperation Division Ministry of Digital Development and Communications The Government of Mongolia Tel: +976 51 260636 www.mddc.gov.mn

4 4

Possible clarification to the tzalloc() documentation
by Guy Harris Jan. 5, 2024

Jan. 5, 2024

The newtzset.3 man page says The tzalloc function allocates and returns a timezone object described by TZ. If TZ is not a valid timezone description, or if the object cannot be allocated, tzalloc returns a null pointer and sets errno. This doesn't explicitly say that TZ == NULL amounts to "not a valid timezone description", nor does it explicitly say that implementation-defined default timezone information is used. (The latter is the behavior the code implements.) It does say If TZ is null, the best available approximation to local (wall clock) time, as specified by the tzfile(5)-format file localtime in the system time conversion information directory, is used. If TZ is the empty string, UT is used, with the abbreviation "UTC" and without leap second correction; please see newctime(3) for more about UT, UTC, and leap seconds. If TZ is nonnull and nonempty: if the value begins with a colon, it is used as a pathname of a file from which to read the time conversion information; if the value does not begin with a colon, it is first used as the pathname of a file from which to read the time conversion information, and, if that file cannot be read, is used directly as a specification of the time conversion information. after describing taser: The tzset function acts like tzalloc(getenv("TZ")), except it saves any resulting timezone object into internal storage that is accessed by localtime, localtime_r, and mktime. The anonymous shared timezone object is freed by the next call to tzset. If the implied call to tzalloc fails, tzset falls back on Universal Time (UT). but it might be clearer if the paragraph about tzset followed the "If TZ is..." text. Perhaps the "If TZ is not a valid timezone description, or..." text should immediacy follow the "If TZ is..." text, e.g. The tzalloc function allocates and returns a timezone object described by TZ. If TZ is null, the best available approximation to local (wall clock) time, as specified by the tzfile(5)-format file localtime in the system time conversion information directory, is used. If TZ is the empty string, UT is used, with the abbreviation "UTC" and without leap second correction; please see newctime(3) for more about UT, UTC, and leap seconds. If TZ is nonnull and nonempty: if the value begins with a colon, it is used as a pathname of a file from which to read the time conversion information; if the value does not begin with a colon, it is first used as the pathname of a file from which to read the time conversion information, and, if that file cannot be read, is used directly as a specification of the time conversion information. In the latter case, if TZ is not a valid timezone description, tzalloc returns a null pointer and sets errno. If the object cannot be allocated, or if a file cannot be read, tzalloc returns a null pointer and sets errno. The tzset function acts like tzalloc(getenv("TZ")), except it saves any resulting timezone object into internal storage that is accessed by localtime, localtime_r, and mktime. The anonymous shared timezone object is freed by the next call to tzset. If the implied call to tzalloc fails, tzset falls back on Universal Time (UT). with, if necessary, text reminding people that, if TZ is not seen in the environment, tzalloc(getenv("TZ")) is equivalent to tzalloc(NULL), so "the best available approximation to local (wall clock) time..." is used.

2 1

[PROPOSED 1/3] Avoid expr in tzselect
by Paul Eggert Jan. 2, 2024

Jan. 2, 2024

* tzselect.ksh: Rewrite to not use the expr command. Various implementations have problems or dump core given unusual inputs, so to avoid these issues use awk or sh (which we need to use anyway) instead of using expr. --- tzselect.ksh | 32 ++++++++++++++++++++++---------- 1 file changed, 22 insertions(+), 10 deletions(-) diff --git a/tzselect.ksh b/tzselect.ksh index 2073bccd..cc58db03 100644 --- a/tzselect.ksh +++ b/tzselect.ksh @@ -40,6 +40,9 @@ REPORT_BUGS_TO=tz(a)iana.org # The substr avoids problems when VALUE is of the form X=Y and would be # misinterpreted as an assignment. +# This script does not want path expansion. +set -f + # Specify default values for environment variables if they are unset. : ${AWK=awk} : ${TZDIR=`pwd`} @@ -113,7 +116,8 @@ then else doselect() { # Field width of the prompt numbers. - select_width=`expr $# : '.*'` + print_nargs_length="BEGIN {print length(\"$#\");}" + select_width=`$AWK "$print_nargs_length"` select_i= @@ -124,14 +128,14 @@ else select_i=0 for select_word do - select_i=`expr $select_i + 1` + select_i=`$AWK "BEGIN { print $select_i + 1 }"` printf >&2 "%${select_width}d) %s\\n" $select_i "$select_word" done;; *[!0-9]*) echo >&2 'Please enter a number in range.';; *) if test 1 -le $select_i && test $select_i -le $#; then - shift `expr $select_i - 1` + shift `$AWK "BEGIN { print $select_i - 1 }"` select_result=$1 break fi @@ -165,7 +169,7 @@ do esac done -shift `expr $OPTIND - 1` +shift `$AWK "BEGIN { print $OPTIND - 1 }"` case $# in 0) ;; *) say >&2 "$0: $1: unknown argument"; exit 1 @@ -439,7 +443,12 @@ while continent=$select_result case $continent in Americas) continent=America;; - *" "*) continent=`expr "$continent" : '\''$[^ ]*$'\''` + *) + # Get the first word of $continent. Path expansion is disabled + # so this works even with "*", which should not happen. + IFS=" " + for continent in $continent ""; do break; done + IFS=$newline;; esac case $zonetabtype,$continent in zonenow,*) ;; @@ -746,15 +755,18 @@ while do TZdate=`LANG=C TZ="$TZ_for_date" date` UTdate=`LANG=C TZ=UTC0 date` - TZsec=`expr "$TZdate" : '.*:$[0-5][0-9]$'` - UTsec=`expr "$UTdate" : '.*:$[0-5][0-9]$'` - case $TZsec in - $UTsec) + if $AWK ' + function getsecs(d) { + return match(d, /.*:[0-5][0-9]/) ? substr(d, RLENGTH - 1, 2) : "" + } + BEGIN { exit getsecs(ARGV[1]) != getsecs(ARGV[2]) } + ' ="$TZdate" ="$UTdate" + then extra_info=" Selected time is now: $TZdate. Universal Time is now: $UTdate." break - esac + fi done -- 2.40.1

1 2

time zone versus time zone...
by Arthur David Olson Jan. 1, 2024

Jan. 1, 2024

...over time, per Google ngrams. The beginning of the (relative) rise of timezone predates the first 1986 release of the time zone package. @dashdashado https://books.google.com/ngrams/graph?content=time+zone%2Ctimezone&year_sta…

1 0

[PROPOSED 1/2] Comics update
by Paul Eggert Jan. 1, 2024

Jan. 1, 2024

Add xkcd’s “Daylight Saving Choice”, “Date Line” and “DateTime”, along with today’s Frazz and FoxTrot. Remove Dilbert, which had a bad link. --- tz-art.html | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/tz-art.html b/tz-art.html index e3be5f29..aa044313 100644 --- a/tz-art.html +++ b/tz-art.html @@ -507,7 +507,10 @@ along with the panels "<a href="https://xkcd.com/2050/">6/6 Time</a>" (2018-09-24), "<a href="https://xkcd.com/2092/">Consensus New Year</a>" (2018-12-31), "<a href="https://xkcd.com/2266/">Leap Smearing</a>" (2020-02-10), -and "<a href="https://xkcd.com/2594/">Consensus Time</a>" (2022-03-16). +"<a href="https://xkcd.com/2594/">Consensus Time</a>" (2022-03-16), +"<a href="https://xkcd.com/2846/">Daylight Saving Choice</a>" (2023-10-25), +"<a href="https://xkcd.com/2854/">Date Line</a>" (2023-11-13), +and "<a href="https://xkcd.com/2867/">DateTime</a>" (2023-12-13). The related book What If? has an entry "<a href="https://what-if.xkcd.com/26/">Leap Seconds</a>" (2012-12-31). </li> @@ -520,9 +523,13 @@ Before Swine (2016-11-06)</a>. Stonehenge is abandoned in <a href="https://www.gocomics.com/nonsequitur/2017/03/12">Non Sequitur (2017-03-12)</a>. +</li> <li> -The boss freaks out in <a -href="https://dilbert.com/strip/1998-03-14">Dilbert (1998-03-14)</a>. +Caulfield proposes changing clocks just once a year in +<a href="https://www.gocomics.com/frazz/2023/12/31">Frazz +(2023-12-31)</a>, while Peter and Jason go multi-lingual and -zonal in +<a href="https://www.gocomics.com/foxtrot/2023/12/31">FoxTrot +(the same day)</a>. </li> <li> Peppermint Patty: "What if the world comes to an end tonight, Marcie?" -- 2.40.1

1 1

Possible zic bug in far future calculations?
by Gilmore Davidson Dec. 30, 2023

Dec. 30, 2023

I was compiling the 2023d release for the Moment Timezone JS library and noticed some oddities in the diff of the generated files. A lot of tests are auto-generated from the data for each tzdb release, making sure the library correctly handles each transition defined in `zdump` output. For 2023d, a handful of zones in North America added a lot more transition tests after the year 2400. These transitions were apparently missing in earlier releases, and appear to have been fixed by commit 35c116b7 ("Fix zic bug with Palestine after 2075"), which makes sense. But a strange case I noticed is specific to `America/Ciudad_Juarez`. In 2023c its overall zdump output ended at 2422, not 2499 like other zones. In 2023d zdump does go to 2499, but there's now a weird set of transitions in 2422. Compiling zic/zdump for 2023c and getting the data for 2421-2423: $ /tmp/tz/2023c/git/zdump -V -c2421,2424 /tmp/tz/2023c/zic/America/Ciudad_Juarez /tmp/tz/2023c/zic/America/Ciudad_Juarez Sun Mar 14 08:59:59 2421 UT = Sun Mar 14 01:59:59 2421 MST isdst=0 gmtoff=-25200 /tmp/tz/2023c/zic/America/Ciudad_Juarez Sun Mar 14 09:00:00 2421 UT = Sun Mar 14 03:00:00 2421 MDT isdst=1 gmtoff=-21600 /tmp/tz/2023c/zic/America/Ciudad_Juarez Sun Nov 7 07:59:59 2421 UT = Sun Nov 7 01:59:59 2421 MDT isdst=1 gmtoff=-21600 /tmp/tz/2023c/zic/America/Ciudad_Juarez Sun Nov 7 08:00:00 2421 UT = Sun Nov 7 01:00:00 2421 MST isdst=0 gmtoff=-25200 /tmp/tz/2023c/zic/America/Ciudad_Juarez Sun Mar 13 08:59:59 2422 UT = Sun Mar 13 01:59:59 2422 MST isdst=0 gmtoff=-25200 /tmp/tz/2023c/zic/America/Ciudad_Juarez Sun Mar 13 09:00:00 2422 UT = Sun Mar 13 03:00:00 2422 MDT isdst=1 gmtoff=-21600 /tmp/tz/2023c/zic/America/Ciudad_Juarez Sun Nov 6 07:59:59 2422 UT = Sun Nov 6 01:59:59 2422 MDT isdst=1 gmtoff=-21600 /tmp/tz/2023c/zic/America/Ciudad_Juarez Sun Nov 6 08:00:00 2422 UT = Sun Nov 6 01:00:00 2422 MST isdst=0 gmtoff=-25200 Doing the same for 2023d: $ /tmp/tz/2023d/git/zdump -V -c2421,2424 /tmp/tz/2023d/zic/America/Ciudad_Juarez /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Mar 14 08:59:59 2421 UT = Sun Mar 14 01:59:59 2421 MST isdst=0 gmtoff=-25200 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Mar 14 09:00:00 2421 UT = Sun Mar 14 03:00:00 2421 MDT isdst=1 gmtoff=-21600 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Nov 7 07:59:59 2421 UT = Sun Nov 7 01:59:59 2421 MDT isdst=1 gmtoff=-21600 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Nov 7 08:00:00 2421 UT = Sun Nov 7 01:00:00 2421 MST isdst=0 gmtoff=-25200 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Mar 13 08:59:59 2422 UT = Sun Mar 13 01:59:59 2422 MST isdst=0 gmtoff=-25200 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Mar 13 09:00:00 2422 UT = Sun Mar 13 03:00:00 2422 MDT isdst=1 gmtoff=-21600 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Nov 6 07:59:59 2422 UT = Sun Nov 6 01:59:59 2422 MDT isdst=1 gmtoff=-21600 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Nov 6 08:00:00 2422 UT = Sun Nov 6 01:00:00 2422 MST isdst=0 gmtoff=-25200 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Nov 6 08:00:00 2422 UT = Sun Nov 6 01:00:00 2422 MST isdst=0 gmtoff=-25200 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Nov 6 08:00:01 2422 UT = Sun Nov 6 02:00:01 2422 CST isdst=0 gmtoff=-21600 /tmp/tz/2023d/zic/America/Ciudad_Juarez Wed Nov 30 05:59:59 2422 UT = Tue Nov 29 23:59:59 2422 CST isdst=0 gmtoff=-21600 /tmp/tz/2023d/zic/America/Ciudad_Juarez Wed Nov 30 06:00:00 2422 UT = Tue Nov 29 23:00:00 2422 MST isdst=0 gmtoff=-25200 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Mar 12 08:59:59 2423 UT = Sun Mar 12 01:59:59 2423 MST isdst=0 gmtoff=-25200 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Mar 12 09:00:00 2423 UT = Sun Mar 12 03:00:00 2423 MDT isdst=1 gmtoff=-21600 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Nov 5 07:59:59 2423 UT = Sun Nov 5 01:59:59 2423 MDT isdst=1 gmtoff=-21600 /tmp/tz/2023d/zic/America/Ciudad_Juarez Sun Nov 5 08:00:00 2423 UT = Sun Nov 5 01:00:00 2423 MST isdst=0 gmtoff=-25200 Note that consecutive seconds on Nov 6 2422 go MDT -> MST -> CST, then back to MST on Nov 30. (For diagnostic purposes... I'm running these tests on macOS 14.2.1 with default `make` and `make install`, no extra flags.) I don't particularly care about (or believe) the accuracy of the data that far in the future, but the wonky transitions make me think there's a bug lurking in zic that might affect other transitions at some point, if the conditions are right. I found it interesting that the data previously cut off exactly 400 years after the zone's last defined "until" rule in `northamerica`. Digging further, the other zones that had incomplete data follow the same pattern: `America/Indiana/Petersberg` ended in 2407 (last defined "until" in 2007). `America/Indiana/Vincennes` the same. `America/North_Dakota/Belulah` ended in 2410 (last defined "until" in 2010). These other zones don't appear to have the same consecutive transition problem (i.e. they're not buggy any more), but the 400 year pattern is telling. Cheers, Gil

2 2