- tz - lists.iana.org

Re: [tz] [PROPOSED] Merge timezones that are alike since 1970
by Stephen Trainor June 2, 2021

June 2, 2021

> To me, the two tables provide very different needs to two very different sets of users. Let the O/S teams use table 1, let the history-related app developers use a constantly improving backtable. As a history-related app developer (astronomy), I can only speak authoritatively for my own code, but I suspect the same applies to the vast majority of similar apps out there: I’ve never consumed tzdb data directly, but rely instead on OS implementations for historical data in native applications (and NPM libraries for web applications). I’m doubtful this distinction between sets of users is actually valid in practical terms, even though consumption of historical data is likely a drop in the overall ocean. Even if developers could consume backzone information directly, will they? Reimplementing tz-related logic in order to do so would be a big task from my perspective. Stephen Sent from my iPhone

1 0

research on TZ list
by BASTIAN Michelle June 1, 2021

June 1, 2021

Hi all, I'm a researcher at the University of Edinburgh, currently working on a book about redesigning clocks. My background is in philosophy, though quite interdisciplinary. I'm interested in the disparity between those responsible for the technical aspects of time keeping, who generally understand clock time to be malleable and adjustable, and wider perceptions in the arts and humanities that clocks are objective. The TZ list is a great case study to show this malleability, so I'm hoping to draw on the archives to develop a chapter for the book, where I'll also be talking about leap smearing. I've been in touch with the owners and the list is regarded as being in the public domain and transparent ie ICANN and its subsidiaries are allowed to "Maintain archival records of a User's participation for historical and research purposes, subject to retention limits imposed by applicable laws" and "To publish a User's comments or feedback along with a User's name for the benefit of others and otherwise to comply with our accountability and transparency principles". However, in terms of transparency from my side I wanted to let you all know about this project and that once the section is drafted, I will contact those that I reference to ensure that you are okay for quotes to be used in the way I have. No need to respond to me if you are okay with it, but I did want to offer the opportunity to correct me, to remove the quote, or to be anonymised as preferred. I could then share the paper with the group if that was of interest. I'm very happy to answer any questions, do contact me directly if you'd like to, and thanks for all the great work you are doing. Finally, if anyone is interested in the project more widely, I wrote a short paper that was published as part of the Science of Time conference at Harvard in 2016 which can be accessed here https://link.springer.com/chapter/10.1007%2F978-3-319-59909-0_41 Best wishes, Michelle. --- Dr Michelle Bastian Senior Lecturer in Environmental Humanities ESALA, Edinburgh College of Art, University of Edinburgh Level 1, Room 303B, The Maltings | Minto House, 20-22 Chambers Street, Edinburgh, EH1 1JZ | 0131 651 5779 Work hours: I normally work 7am-3pm M-F. Latest publications: Whale falls, suspended ground, and extinctions never known<https://read.dukeupress.edu/environmental-humanities/article/12/2/454/16699…> (Environmental Humanities, 2020) Open access Retelling Time in Grassroots Sustainable Economy Movements<https://doi-org.ezproxy.is.ed.ac.uk/10.1080/2373566X.2019.1583589> (Geohumanities, 2019) Open access Time & Society<https://journals.sagepub.com/home/tas> | Edinburgh Environmental Humanities Network<http://www.environmentalhumanities.ed.ac.uk/> | Temporal Belongings<http://www.temporalbelongings.org/> | Extinction Studies<http://extinctionstudies.org/> | ESALA Declares<http://extinctionstudies.org/> | The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th' ann an Oilthigh Dh?n ?ideann, cl?raichte an Alba, ?ireamh cl?raidh SC005336.

1 0

[PROPOSED] * northamerica: Comment on Attu+Kiska 1942/3.
by Paul Eggert May 28, 2021

May 28, 2021

--- northamerica | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/northamerica b/northamerica index 7edd8ef..a2f2b43 100644 --- a/northamerica +++ b/northamerica @@ -729,7 +729,11 @@ Zone America/Adak 12:13:22 - LMT 1867 Oct 19 12:44:35 -11:00 US B%sT 1983 Oct 30 2:00 -10:00 US AH%sT 1983 Nov 30 -10:00 US H%sT -# The following switches don't quite make our 1970 cutoff. +# The following switches don't make our 1970 cutoff. +# +# Kiska observed Tokyo date and time during Japanese occupation from +# 1942-06-06 to 1943-07-29, and similarly for Attu from 1942-06-07 to +# 1943-05-29 (all dates American). Both islands are now uninhabited. # # Shanks writes that part of southwest Alaska (e.g. Aniak) # switched from -11:00 to -10:00 on 1968-09-22 at 02:00, -- 2.27.0

1 0

[PROPOSED] Replace Pacific/Enderbury with Pacific/Kanton
by Paul Eggert May 28, 2021

May 28, 2021

When I added Pacific/Enderbury in 1993, I thought it was the most-populous location in its timezone. I was wrong - it has been uninhabited since 1942. I discovered my mistake this week when doing the recent timezone-coalescing changes. It shouldn’t be surprising that this problem has not been reported, as only two dozen people live in the timezone, they’re rotated in and out, and they likely don’t have a good Internet connection. Leaving the name alone wouldn’t work because Pacific/Enderbury should be at -00 now, our convention for uninhabited locations. So, replace the name with Pacific/Kanton. By strange coincidence, Kanton has been in the news recently, for reasons similar to why Enderbury was in the news in the 1930s; see: https://www.thedrive.com/the-war-zone/40471/china-wants-to-revive-a-strateg… * NEWS: Mention this. * australasia, zone.tab, zone1970.tab (Pacific/Kanton): New zone, replacing ... * backward (Pacific/Enderbury): New backward-compatibility link * backzone: Copy of old data, with fixes for uninhabited times, which includes the current time. --- NEWS | 13 +++++++++++-- australasia | 19 ++++++++++++++++++- backward | 1 + backzone | 12 ++++++++++++ zone.tab | 2 +- zone1970.tab | 2 +- 6 files changed, 44 insertions(+), 5 deletions(-) diff --git a/NEWS b/NEWS index 04c45e9..53890a7 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,13 @@ News for the tz database Unreleased, experimental changes + Changes to zone name + + Rename Pacific/Enderbury to Pacific/Kanton. When we added + Enderbury in 1993, we did not know that it is uninhabited and that + Kanton (population two dozen) is the only inhabited location in + that timezone. The old name is now a backward-compatility link. + Changes to past timestamps Correct many pre-1993 transitions, fixing entries originally @@ -14,11 +21,13 @@ Unreleased, experimental changes - Guyana: corrected LMT for Georgetown; the introduction of standard time in 1911, not 1915; and corrections to 1975 and 1992 transitions + - Kanton: uninhabited before 1937-08-31 - Niue: observed -11:20 in 1951-1978 - Portugal: DST was observed in 1950 - Tonga: adopted standard time in 1945 not 1901, and moved from +12:20 to +13 in 1961 not 1941 Additional fixes to entries in the 'backzone' file include: + - Enderbury: inhabited only 1860/1885 and 1938-03-06/1942-02-09 - The Gambia: 1933 and 1942 transitions - Malawi: several 1911 through 1925 transitions - Sierra Leone: several 1913 through 1941 transitions, and DST @@ -955,8 +964,8 @@ Release 2018d - 2018-03-22 07:05:46 -0700 Institute in Montevideo. (Thanks to Jeremie Bonjour, Tim Parenti, and Michael Deckers.) - Enderbury and Kiritimati skipped New Year's Eve 1994, not - New Year's Day 1995. (Thanks to Kerry Shetline.) + East Kiribati skipped New Year's Eve 1994, not New Year's Day 1995. + (Thanks to Kerry Shetline.) Fix the 1912-01-01 transition for Portugal and its colonies. This transition was at 00:00 according to the new UT offset, not diff --git a/australasia b/australasia index 8e952ad..5cbc0c8 100644 --- a/australasia +++ b/australasia @@ -457,7 +457,7 @@ Zone Pacific/Guam -14:21:00 - LMT 1844 Dec 31 # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone Pacific/Tarawa 11:32:04 - LMT 1901 # Bairiki 12:00 - +12 -Zone Pacific/Enderbury -11:24:20 - LMT 1901 +Zone Pacific/Kanton 0 - -00 1937 Aug 31 -12:00 - -12 1979 Oct -11:00 - -11 1994 Dec 31 13:00 - +13 @@ -1735,6 +1735,23 @@ Zone Pacific/Efate 11:13:16 - LMT 1912 Jan 13 # Vila # One source for this is page 202 of: Bartky IR. One Time Fits All: # The Campaigns for Global Uniformity (2007). +# Kanton + +# From Paul Eggert (2021-05-27): +# Kiribati's +13 timezone is represented by Kanton, its only populated +# island. (It was formerly spelled "Canton", but Gilbertese lacks "C".) +# Kanton was settled on 1937-08-31 by two British radio operators +# <https://history.state.gov/historicaldocuments/frus1937v02/d94>; +# Americans came the next year and built an airfield, partly to +# establish airline service and perhaps partly anticipating the +# next war. Aside from the war, the airfield was used by commercial +# airlines until long-range jets became standard; although currently +# for emergency use only, China says it is considering rebuilding the +# airfield for high-end niche tourism. Kanton has about two dozen +# people, caretakers who rotate in from the rest of Kiribati in 2-5 +# year shifts, and who use some of the leftover structures +# <http://pipa.neaq.org/2012/06/images-of-kanton-island.html>. + # Kwajalein # From an AP article (1993-08-22): diff --git a/backward b/backward index 9e22754..0fec5e4 100644 --- a/backward +++ b/backward @@ -208,6 +208,7 @@ Link Pacific/Chatham NZ-CHAT Link America/Denver Navajo Link Asia/Shanghai PRC Link Pacific/Port_Moresby Pacific/Chuuk +Link Pacific/Kanton Pacific/Enderbury Link Pacific/Tarawa Pacific/Funafuti Link Pacific/Honolulu Pacific/Johnston Link Pacific/Tarawa Pacific/Majuro diff --git a/backzone b/backzone index f5b20fa..4d69a3f 100644 --- a/backzone +++ b/backzone @@ -1566,6 +1566,18 @@ Zone Pacific/Chuuk -13:52:52 - LMT 1844 Dec 31 Link Pacific/Chuuk Pacific/Truk Link Pacific/Chuuk Pacific/Yap +# Phoenix Islands, Kiribati +# From Paul Eggert (2021-05-27): +# Enderbury was inhabited 1860/1880s to mine guano, and 1938-03-06/1942-02-09 +# for aviation (ostensibly commercial, but military uses foreseen). +# The 19th-century dates are approximate. See Pacific/Kanton for +# the currently-inhabited representative for this timezone. +Zone Pacific/Enderbury 0 - -00 1860 + -11:24:20 - LMT 1885 + 0 - -00 1938 Mar 6 + -12:00 - -12 1942 Feb 9 + 0 - -00 + # Tuvalu Zone Pacific/Funafuti 11:56:52 - LMT 1901 12:00 - +12 diff --git a/zone.tab b/zone.tab index cbf4b91..e2062cf 100644 --- a/zone.tab +++ b/zone.tab @@ -232,7 +232,7 @@ KE -0117+03649 Africa/Nairobi KG +4254+07436 Asia/Bishkek KH +1133+10455 Asia/Bangkok KI +0125+17300 Pacific/Tarawa Gilbert Islands -KI -0308-17105 Pacific/Enderbury Phoenix Islands +KI -0247-17143 Pacific/Kanton Phoenix Islands KI +0152-15720 Pacific/Kiritimati Line Islands KM -1141+04316 Africa/Nairobi KN +1718-06243 America/Puerto_Rico diff --git a/zone1970.tab b/zone1970.tab index a02d94d..6b9d288 100644 --- a/zone1970.tab +++ b/zone1970.tab @@ -188,7 +188,7 @@ JP +353916+1394441 Asia/Tokyo KE,DJ,ER,ET,KM,MG,SO,TZ,UG,YT -0117+03649 Africa/Nairobi KG +4254+07436 Asia/Bishkek KI,MH,TV,UM,WF +0125+17300 Pacific/Tarawa Gilberts, Marshalls, Tuvalu, Wallis & Futuna, Wake -KI -0308-17105 Pacific/Enderbury Phoenix Islands +KI -0247-17143 Pacific/Kanton Phoenix Islands KI +0152-15720 Pacific/Kiritimati Line Islands KP +3901+12545 Asia/Pyongyang KR +3733+12658 Asia/Seoul -- 2.27.0

1 0

So, about those LMT offsets
by Tom Lane May 24, 2021

May 24, 2021

As long as we're considering decreasing the historical fidelity of assorted pre-1970 timestamps, I'd like to make a modest suggestion: forget all the "LMT" offsets for years before standardized timezones prevailed, and just assume that the oldest documented standard-time offset in each zone goes back indefinitely far. The reason I suggest this is that we regularly get questions on the Postgres lists from novices who are confused by this behavior (pardon the SQL-isms): postgres=# set timezone = 'UTC'; SET postgres=# select timestamptz '1884-01-01 12:00 America/New_York'; timestamptz ------------------------ 1884-01-01 17:00:00+00 (1 row) This is, of course, saying that noon in New York translates to 1700 UT ... postgres=# select timestamptz '1883-01-01 12:00 America/New_York'; timestamptz ------------------------ 1883-01-01 16:56:02+00 (1 row) ... uh, what? The novices are definitely not expecting that, and they don't find it helpful. We have to explain it away as "that's what tzdb says", but it's still unhelpful. It's even sillier when you consider postgres=# select timestamptz '1752-09-10 12:00 America/New_York'; timestamptz ------------------------ 1752-09-10 16:56:02+00 (1 row) as calendar experts will recall that no such date was recognized in the British colonies. So although it's debatable whether we even know what day it is, for sure we know the UTC offset to the second. So basically, if we're willing to use proleptic Gregorian calendar for years before anyone was actually using that calendar, it's not very clear why we shouldn't use proleptic standard time too. I'd be willing to consider implementing that behavior in Postgres if I could tell (a) that a given offset is LMT not standardized time and (b) what the zone's oldest standardized offset is. But AFAICT that's not possible without mucking with the behavior of localtime.c, which I'd much prefer not to. So ... how about just dropping this oddity from the source data? regards, tom lane

9 17

Re: [tz] Vanguard vs. "main" vs. rearguard
by Paul Eggert May 20, 2021

May 20, 2021

On 5/19/21 4:35 PM, Kerry Shetline wrote: > Can you show me an example of what the format of a three-mode set of data would look like? I doubt it. I don't think we've ever done it. If we were to do it (I hope not), we'd probably have to change ziguard.awk to implement it. There may be an expectation here that the vanguard/main/rearguard formats are well-specified. They're not. They're purely a hack, they're implemented only by ziguard.awk, we don't even need vanguard any more, and I hope the need for rearguard goes away as well. Perhaps in the future we'll need to do this sort of delayed-implementation again; when that happens we may do it in an entirely different way.

1 0

Re: [tz] Vanguard vs. "main" vs. rearguard
by Kerry Shetline May 19, 2021

May 19, 2021

I think I’ve answered my own question. First of all, I can select between the various versions by reading from one of the vanguard.zi, rearguard.zi, or main.zi files. (I had been reading all of the files like africa, europe, northamerica, etc., separately at first.) Then whatever I want or don’t want to use is already commented out or uncommented as needed. Secondly, even if I’m reading those other files rather than the .zi files, I gather that, in my Europe/Dublin example, the vanguard and main data are the same, but if rearguard and main had been the same, it would be the vanguard section that was commented out, and the rearguard section would have been uncommented. I take it from this that, for any given vanguard/rearguard section, you can’t have all three formats defined differently, but rather “main” will either be identical to one of vanguard or rearguard.

2 1

Vanguard vs. "main" vs. rearguard
by Kerry Shetline May 19, 2021

May 19, 2021

As far as I can tell, their are only four sections in the current tzdb marked as vanguard/rearguard, two sections in the europe for Europe/Dublin and Europe/Prague, and two in the africa file for Africa/Windhoek. What I’m confused about is references I’ve seen to a “main” format, like this: > Changes to future timestamps > > Guess that Morocco will continue to fall back just before and > spring forward just after Ramadan, the practice since 2012. > (Thanks to Maamar Abdelkader.) This means Morocco will observe > negative DST during Ramadan in main and vanguard formats, and in > rearguard format it stays in the +00 timezone and observes > ordinary DST in all months other than Ramadan… At least from the current examples, it looks like one would have to choose either Vanguard or Rearguard, period. There is no middle ground of “main” when I look at a case like this below: # Zone NAME STDOFF RULES FORMAT [UNTIL] Zone Europe/Dublin -0:25:00 - LMT 1880 Aug 2 -0:25:21 - DMT 1916 May 21 2:00s -0:25:21 1:00 IST 1916 Oct 1 2:00s 0:00 GB-Eire %s 1921 Dec 6 # independence 0:00 GB-Eire GMT/IST 1940 Feb 25 2:00s 0:00 1:00 IST 1946 Oct 6 2:00s 0:00 - GMT 1947 Mar 16 2:00s 0:00 1:00 IST 1947 Nov 2 2:00s 0:00 - GMT 1948 Apr 18 2:00s 0:00 GB-Eire GMT/IST 1968 Oct 27 # Vanguard section, for zic and other parsers that support negative DST. 1:00 Eire IST/GMT # Rearguard section, for parsers lacking negative DST; see ziguard.awk. # 1:00 - IST 1971 Oct 31 2:00u # 0:00 GB-Eire GMT/IST 1996 # 0:00 EU GMT/IST # End of rearguard section. If there is a middle ground here, neither Vanguard or Rearguard, what is it? And if there are no current examples with such a middle ground, what would a middle ground of neither Vanguard or Rearguard look like?

1 0

DKIM misconfiguration of this mailing list
by Yves Goergen May 18, 2021

May 18, 2021

Hello, I'm having trouble receiving messages from this mailing list because many of them have a broken DKIM signature. I guess that's because the mailing list is not configured properly to survive in today's e-mail world. If a message with a DKIM signature is sent to this list (like mine), they're forwarded to all subscribers without correcting that signature but at the same time modifying subject, body or sender. Maybe somebody would like to take a look at that to ensure that messages from this list can still be delivered. This is an article I found about the topic, it might be helpful in fixing the problems. https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html I'm writing to the list directly because list owners never seem to respond to such issues. Several other mailing lists I'm subscribed to have the same issue. If you'd like me to read your reply, please CC me as well to make sure your message arrives here. -Yves

2 1

Time Zone and Daylight Saving Time Customer Service Stories
by Brian Inglis May 13, 2021

May 13, 2021

Just came across a source of articles about Time Zones and Daylight Saving Time from the perspective of Customer Service, or other staff dealing with them, across the globe, at NotAlwaysRight.com. The tone reminds me of articles in The Register. My attention was first drawn by a series of articles entitled "No Fortitude for Longitude" and I have attached some links to that series and to results from search queries on the topics. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]

1 0

Re: [tz] IANA .tar.gz files with incorrect checksums
by Paul Eggert May 13, 2021

May 13, 2021

On 5/12/21 4:30 PM, Peter Adelman wrote: > I am contacting you to let you know that some of the old releases of the > IANA time zones databases are missing (or perhaps have incorrect) > checksums in their .tars. The Julia language uses the IANA Time Zone > Databases for its TimeZones.jl package, and in the language's most > recent minor release (1.6) they started failing extractions where the > header checksum didn't match the standard. > > Here are two related tickets: > * https://github.com/JuliaTime/TimeZones.jl/issues/325 > <https://github.com/JuliaTime/TimeZones.jl/issues/325> > * https://github.com/JuliaIO/Tar.jl/issues/111 > <https://github.com/JuliaIO/Tar.jl/issues/111> > > Of the tzdata___.tar.gzs that I have looked at (I think that I explored > all of them while trying to build my Julia package), these have > problematic tar checksums: > 93g > 94a/b/d/e/f/h > 95b/c/d/e/f/g/h/i/k/l/m > 96a/b/c/d/e/h/i > 1996n > 1997b/c > 1999f > > I checked two of them by hand (1997b and one other that I didn't note) > and both had blank header checksum bytes (0). ( > https://www.gnu.org/software/tar/manual/html_node/Standard.html > <https://www.gnu.org/software/tar/manual/html_node/Standard.html> ) > > Anyway, the glory of standards releases is that they don't change so > obviously I understand not changing it, but I thought I'd reach out with > the information anyway. Those old tarballs were built by old SunOS tar, which computed some checksums incompatibly with POSIX <https://www.gnu.org/software/tar/manual/html_node/Checksumming.html> and which put leading spaces into numeric fields, contra POSIX. GNU Tar is generous and accepts these old tarballs, but perhaps TimeZones.jl has never had to deal with old SunOS tar, or maybe Julia's tarball-extracting library has a "let's be generous in what we accept" option that TimeZones.jl could enable. I installed the attached to tz-link to document some of this. This patch assumes that 1999g and later are OK (I haven't checked this).

2 1

About missing country in your Time Zone Database?
by Sadiku, Besnik May 11, 2021

May 11, 2021

Hello there IANA personnel, I am currently taking a Python class and learning about using Time Zone and noticed that Kosovo is missing in the Time Zone Database list. Please, I would to request to add in your Time Zone Database the country KOSOVO and its capital PRISHTINA? Thank you and I appreciated. Sincerely, ******************************************* * Besnik Sadiku, BS in M.C.S. and Web Dev. & Admin. * Business Analyst 2 / Certified * Office: (608) 741-5629 * Cell: (262) 473-9511 * e-mail: bsadiku(a)mhemail.org<mailto:bsadiku@mhemail.org> ******************************************* [cid:image001.png@01D201CE.DEAEBCD0]

4 6

(no subject)
by Cool Gab19 May 11, 2021

May 11, 2021

can you add UTC+15:00 "Future Standard Time" time zone it was 1 hour ahead from all 24 hour world time zone and it doesn't have any current region or countries same to Universal Time which can be used anywhere and i do really know that we need calculations for these but please put this thing on your database so i can able to see this on my devices settings.

2 1

[PATCH] Definite article for Bahamas, Gambia
by Paul Eggert May 10, 2021

May 10, 2021

* NEWS, backzone, iso3166.tab, northamerica: Put "The" in front of "Bahamas" and "Gambia"; this is a common style and is preferred by the respective governments. --- NEWS | 4 ++-- backzone | 2 +- iso3166.tab | 4 ++-- northamerica | 2 +- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/NEWS b/NEWS index 67fb000..6d1cd09 100644 --- a/NEWS +++ b/NEWS @@ -19,7 +19,7 @@ Unreleased, experimental changes - Tonga: adopted standard time in 1945 not 1901, and moved from +12:20 to +13 in 1961 not 1941 Additional fixes to entries in the 'backzone' file include: - - Gambia: 1933 and 1942 transitions + - The Gambia: 1933 and 1942 transitions - Malawi: several 1911 through 1925 transitions - Sierra Leone: several 1913 through 1941 transitions, and DST was NOT observed in 1957 through 1962 @@ -148,7 +148,7 @@ Release 2020e - 2020-12-22 15:14:34 -0800 Correct many pre-1986 transitions, fixing entries originally derived from Shanks. The fixes include: - Australia: several 1917 through 1971 transitions - - Bahamas: several 1941 through 1945 transitions + - The Bahamas: several 1941 through 1945 transitions - Bermuda: several 1917 through 1956 transitions - Belize: several 1942 through 1968 transitions - Ghana: several 1915 through 1956 transitions diff --git a/backzone b/backzone index 9ebf9d2..8e4f97a 100644 --- a/backzone +++ b/backzone @@ -101,7 +101,7 @@ Zone Africa/Bamako -0:32:00 - LMT 1912 Zone Africa/Bangui 1:14:20 - LMT 1912 1:00 - WAT -# Gambia +# The Gambia # From P Chan (2020-12-09): # Standard time of GMT-1 was adopted on 1933-04-01. On 1942-02-01, GMT was # adopted as a war time measure. This was made permanent in 1946. diff --git a/iso3166.tab b/iso3166.tab index a4ff61a..e7ab54d 100644 --- a/iso3166.tab +++ b/iso3166.tab @@ -54,7 +54,7 @@ BN Brunei BO Bolivia BQ Caribbean NL BR Brazil -BS Bahamas +BS The Bahamas BT Bhutan BV Bouvet Island BW Botswana @@ -107,7 +107,7 @@ GG Guernsey GH Ghana GI Gibraltar GL Greenland -GM Gambia +GM The Gambia GN Guinea GP Guadeloupe GQ Equatorial Guinea diff --git a/northamerica b/northamerica index c7d9274..b27311a 100644 --- a/northamerica +++ b/northamerica @@ -2931,7 +2931,7 @@ Zone America/Tijuana -7:48:04 - LMT 1922 Jan 1 0:11:56 # Antigua and Barbuda # See America/Port_of_Spain. -# Bahamas +# The Bahamas # # For 1899 Milne gives -5:09:29.5; round that. # -- 2.27.0

2 1

[PROPOSED 1/2] Omit duplicate Link lines in ziguard output
by Paul Eggert May 10, 2021

May 10, 2021

* ziguard.awk: Later Link lines now comment out earlier ones. Formerly, we relied on ‘zic’ to ignore the earlier lines, but this made for more-confusing ziguard output. This change does not affect zic’s output. --- ziguard.awk | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/ziguard.awk b/ziguard.awk index 7d6f7c9..6888c27 100644 --- a/ziguard.awk +++ b/ziguard.awk @@ -114,15 +114,16 @@ DATAFORM != "main" { } } -# If a Link line is followed by a Zone line for the same data, comment +# If a Link line is followed by a Link or Zone line for the same data, comment # out the Link line. This can happen if backzone overrides a Link -# with a Zone. -/^Link/ { - linkline[$3] = NR -} +# with a Zone or a different Link. /^Zone/ { sub(/^Link/, "#Link", line[linkline[$2]]) } +/^Link/ { + sub(/^Link/, "#Link", line[linkline[$3]]) + linkline[$3] = NR +} { line[NR] = $0 } -- 2.27.0

1 1

JavaScript IANA date/time library, now with support for leap seconds, TAI, TDT
by Kerry Shetline April 29, 2021

April 29, 2021

About two months ago I released the first major version of @tubular/time, a JavaScript/TypeScript npm package for date/time handling, with solid support for IANA timezones, including dealing with weird edge cases like 47-hour days and negative DST and such. I’ve just finished up adding a feature I’ve always wanted to have in a date/time package, and that’s the ability to properly handle and represent leap seconds. Along with that comes conversion to and from TAI (International Atomic Time) and astronomical time systems. https://www.npmjs.com/package/@tubular/time One interesting issue was how to handle a broad range of years (thousands of years forward and backward in time) in a way that was nicely integrated with Universal Coordinated Time. The idea for UTC got something of a wobbly start around 1960, and wasn’t implemented in its current form until 1972. Going forward in time, UTC is only strictly defined for up to six months beyond the next announced leap second, or next announced lack of any leap second on the way. I settled on the following scheme for resolving these issues, and I’m curious what others might think about it: * For all dates prior to 1957, estimated UT1 is in effect. This is most accurate back to 1600, for which there is sufficient astronomical data for reasonable approximate conversions from UT1 to TAI and dynamical time. Further back in time less accurate approximations are in effect. * From 1957-1958, using a sliding weighted average, UT1 transitions to proleptic UTC. * From 1958-1972 proleptic UTC, as proposed by Tony Finch (https://fanf.livejournal.com/69586.html) is used, with the first non-official leap second occurring at 1959-06-30 23:59:60. * From 1972 up until the latest updates provided by the International Bureau of Weights and Measures, well-defined UTC prevails, with the first official leap second occurring at 1972-06-30 23:59:60. * For a year to 18 months after the current time, or after the last defined leap second (whichever is later), a presumed leap-second-free span of UTC is projected to occur. * A sliding weighted average transition from UTC to estimated UT1 follows for the next 365 days. * Formulaic predicted UT1 is used for all later dates and times thereafter. Another project I’ve been working on (which isn’t quite ready for prime time because it’s utterly without documentation) is a new JavaScript timezone compiler. This has replaced an old Java project I used for generating the timezone data used by @tubular/time: https://github.com/kshetline/tubular_time_tzdb

7 16

Re: [tz] JavaScript IANA date/time library, now with support for leap seconds, TAI, TDT
by Kerry Shetline April 27, 2021

April 27, 2021

On Mon, 26 Apr 2021 16:03:59 -0400, John_Sauter via tz wrote: > Based on the way the Earth has been rotating recently, the next leap > second will be around the end of this decade, and it will be a negative > leap second. What kind of hopeless nerd does it make me that I find this an exciting prospect? I’ve taken negative leap seconds to be a nearly completely hypothetical idea, even though I have nevertheless coded diligently to account for the possibility.

2 1

Re: [tz] JavaScript IANA date/time library, now with support for leap seconds, TAI, TDT
by Kerry Shetline April 27, 2021

April 27, 2021

On Mon, 26 Apr 2021 15:06:12 -0600, Paul Gilmartin <PaulGBoulder(a)aim.com> wrote: >> POSIX time is really just UTC without the leap seconds, isn?t it? >> > More precisely, POSIX time counts non-leap seconds since 1972-01-01t00:00:00 UTC. That would be 1970-01-01T00:00:00 UTC. 1972 is, however, the year that the first official leap second (for POSIX not to count) occurred.

1 1

Re: [tz] JavaScript IANA date/time library, now with support for leap seconds, TAI, TDT
by Steve Allen April 26, 2021

April 26, 2021

On Mon 2021-04-26T17:17:13+0100 Tony Finch via tz hath writ: > My aim back then was to sketch what might be a reasonable way to bridge > between pre-atomic time and UTC, for code that can only support an integer > offset between UTC and TAI. If your code supports rubber seconds then it > should probably use the USNO table that records the rate and phase offsets > between 1962 and 1972. (I don't know another source of that table, nor > where you can get a copy while maia.usno.navy.mil is down.) Keep in mind that the USNO numbers only apply to time signals broadcast in the US, and before 1968 they ignore the many microseconds of offset between NBS and USNO. Germany did not start to broadcast the old UTC until the late 1960s, until 1974-01-01 broadcast both old UTC and SAT, and stopped providing old UTC as of 1970-04-01 because it had been deemed illegal. Soviet and Chinese time signals never used the old UTC. Sussing out the particulars for individual cases of national time signals needs finding remnants of the high-acid paper that each national time service used for bulletins issued to its users, and/or diving through the BIH Bulletin Horaire and Circular D to pull out the received timing of each official broadcast. It is much simpler to ignore the 50 to 200 ms jumps that were put into old UTC and say that before 1972 all available sources of civil time provided UT (nevermind the particular flavor, nobody set their clock that accurately) and after 1972 UTC with leap seconds. For civil time I do not see any advantage in a model with greater complexity than just plain UT as the basis time scale before 1972-01-01. This is adequate for any IANA tz library. For precise time no general model applies. Each precise timestamp must be meticulously referenced to the particulars of the clocks that were used to obtain it. No available clocks were using TAI before 1972-01-01, and this does not belong in any IANA tz library. Constructing a model that supposes it is possible to do better is akin to writing The Silmarillion. Look at the BIH plots of the accuracy of clocks https://www.ucolick.org/~sla/leapsecs/BHsHn05p142.html millisecond agreement between different national authorities was not achieved until 1960 during the UK/US experiment that became old UTC. > * TAI is a retrospective timescale; it isn't defined in the future. TAI also cannot be defined prior to mid 1955, and it was not generally availble for use by any system until 1972-01-01 when broadcast time signals began to be based on TAI. The BIPM will never tolerate TAI becoming part of an international agreement. The best that can be hoped for in a new international agreement on time is one (or more) new TAI-like uniform scale which will be offset by some integer number of seconds from TAI. The reason we use UTC is because it is what is in the current international agreement. Everybody involved in the technical aspects eschewed the use of UTC for their systems from before 1972-01-01. Look at the ATSC agreement for a technically-competent time scale. They chose GPS time because it is practically available. ATSC was not bound by international bureaucratic requirements, so they could make that choice. Because it is ultimately controlled by USNO GPS system time will never become part of an international agreement. On Mon 2021-04-26T12:42:19-0400 John Sauter via tz hath writ: > In looking at historical estimates of the rotation of the Earth based > on astronomical observations of occulations and eclipses, I found that > the values of UT1 are reliabe only since 1825. (Nevertheless, my table > of proleptic leap seconds goes back to the year -2000.) Morrison, L. V.; Stephenson, F. R.; Hohenkerk, C. Y.; Zawilski, M. DOI: 10.1098/rspa.2020.0776 Bibliographic Code: 2021RSPSA.47700776M Proceedings of the Royal Society A, Volume 477, Issue 2246, id.20200776 all tabulated at http://astro.ukho.gov.uk/nao/lvm/ That is the place to look, and it will continue to be so for the lifetime of the authors. But what is it mean to ask reliable? That is very much the question given that prior to "reliable" everybody's clock was set to local apparent time. What exactly is the question that is trying to be answered by an algorithm like this? Ultimately it is necessary to model two kinds of time: 1) earth rotation time (which before the 20th century differed by a second or more depending on who was setting the clock) because that is a subdivision of internationally agreed calendar days 2) uniform time (which becomes possible to interpret as atomic time beginning in 1955). -- Steve Allen <sla(a)ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m

3 3

[PROPOSED] Do not assume bytes have 8 bits
by Paul Eggert April 26, 2021

April 26, 2021

* zic.c (convert, convert64): Mask bytes with 0xff before storing them, for portability to machines where bytes have more than 8 bits. Although this is surely only of theoretical interest, we might as well be portable. --- zic.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/zic.c b/zic.c index 88b1531..77a5698 100644 --- a/zic.c +++ b/zic.c @@ -1927,7 +1927,7 @@ convert(uint_fast32_t val, char *buf) unsigned char *const b = (unsigned char *) buf; for (i = 0, shift = 24; i < 4; ++i, shift -= 8) - b[i] = val >> shift; + b[i] = (val >> shift) & 0xff; } static void @@ -1938,7 +1938,7 @@ convert64(uint_fast64_t val, char *buf) unsigned char *const b = (unsigned char *) buf; for (i = 0, shift = 56; i < 8; ++i, shift -= 8) - b[i] = val >> shift; + b[i] = (val >> shift) & 0xff; } static void -- 2.27.0

4 5

[PATCH] Fix potential integer overflow in differ_by_repeat
by Paul Eggert April 26, 2021

April 26, 2021

* localtime.c (differ_by_repeat): Remove, since the subtraction t1 - t0 could in theory overflow in 64-bit TZif data. (tzloadbody): Redo to avoid integer overflow. * private.h (SECSPERREPEAT_BITS): Remove; no longer used. --- localtime.c | 30 ++++++++++++++---------------- private.h | 3 +-- 2 files changed, 15 insertions(+), 18 deletions(-) diff --git a/localtime.c b/localtime.c index 9dd496d..9840b89 100644 --- a/localtime.c +++ b/localtime.c @@ -334,14 +334,6 @@ scrub_abbrs(struct state *sp) } } -static bool -differ_by_repeat(const time_t t1, const time_t t0) -{ - if (TYPE_BIT(time_t) - TYPE_SIGNED(time_t) < SECSPERREPEAT_BITS) - return 0; - return t1 - t0 == SECSPERREPEAT; -} - /* Input buffer for data read from a compiled tz file. */ union input_buffer { /* The first part of the buffer, interpreted as a header. */ @@ -660,20 +652,26 @@ tzloadbody(char const *name, struct state *sp, bool doextend, if (sp->typecnt == 0) return EINVAL; if (sp->timecnt > 1) { + if (sp->ats[0] <= TIME_T_MAX - SECSPERREPEAT) { + time_t repeatat = sp->ats[0] + SECSPERREPEAT; + int repeattype = sp->types[0]; for (i = 1; i < sp->timecnt; ++i) - if (typesequiv(sp, sp->types[i], sp->types[0]) && - differ_by_repeat(sp->ats[i], sp->ats[0])) { + if (sp->ats[i] == repeatat + && typesequiv(sp, sp->types[i], repeattype)) { sp->goback = true; break; - } + } + } + if (TIME_T_MIN + SECSPERREPEAT <= sp->ats[sp->timecnt - 1]) { + time_t repeatat = sp->ats[sp->timecnt - 1] - SECSPERREPEAT; + int repeattype = sp->types[sp->timecnt - 1]; for (i = sp->timecnt - 2; i >= 0; --i) - if (typesequiv(sp, sp->types[sp->timecnt - 1], - sp->types[i]) && - differ_by_repeat(sp->ats[sp->timecnt - 1], - sp->ats[i])) { + if (sp->ats[i] == repeatat + && typesequiv(sp, sp->types[i], repeattype)) { sp->goahead = true; break; - } + } + } } /* Infer sp->defaulttype from the data. Although this default diff --git a/private.h b/private.h index cee3b11..340a354 100644 --- a/private.h +++ b/private.h @@ -642,7 +642,7 @@ time_t time2posix_z(timezone_t, time_t) ATTRIBUTE_PURE; #define TIME_T_MAX_NO_PADDING MAXVAL(time_t, TYPE_BIT(time_t)) /* The extreme time values. These are macros, not constants, so that - any portability problem occur only when compiling .c files that use + any portability problems occur only when compiling .c files that use the macros, which is safer for applications that need only zdump and zic. This implementation assumes no padding if time_t is signed and either the compiler lacks support for _Generic or time_t is not one @@ -727,7 +727,6 @@ char *ctime_r(time_t const *, char *); #define YEARSPERREPEAT 400 /* years before a Gregorian repeat */ #define DAYSPERREPEAT ((int_fast32_t) 400 * 365 + 100 - 4 + 1) #define SECSPERREPEAT ((int_fast64_t) DAYSPERREPEAT * SECSPERDAY) -#define SECSPERREPEAT_BITS 34 /* ceil(log2(SECSPERREPEAT)) */ #define AVGSECSPERYEAR (SECSPERREPEAT / YEARSPERREPEAT) #define TM_SUNDAY 0 -- 2.27.0

1 0

[PROPOSED 1/2] Do not assume unsigned->signed conversion style
by Paul Eggert April 23, 2021

April 23, 2021

* localtime.c (detzcode64): Use int_fast64_t, not uint_fast64_t, for local variable, to avoid an implementation-defined conversion when the variable’s value is returned. --- localtime.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/localtime.c b/localtime.c index 6c88b6e..9dd496d 100644 --- a/localtime.c +++ b/localtime.c @@ -237,7 +237,7 @@ detzcode(const char *const codep) static int_fast64_t detzcode64(const char *const codep) { - register uint_fast64_t result; + register int_fast64_t result; register int i; int_fast64_t one = 1; int_fast64_t halfmaxval = one << (64 - 2); -- 2.27.0

1 1

[PROPOSED 1/2] * SECURITY: New file.
by Paul Eggert April 20, 2021

April 20, 2021

--- SECURITY | 15 +++++++++++++++ 1 file changed, 15 insertions(+) create mode 100644 SECURITY diff --git a/SECURITY b/SECURITY new file mode 100644 index 0000000..40128bc --- /dev/null +++ b/SECURITY @@ -0,0 +1,15 @@ +Please report any sensitive security-related bugs via email to the +tzdb designated coordinators, currently Paul Eggert +<eggert(a)cs.ucla.edu> and Tim Parenti <tim(a)timtimeonline.com>. +Put "tzdb security" at the start of your email's subject line. +We prefer communications to be in English. + +You should receive a response within a week. If not, please follow up +via email to make sure we received your original message. + +If we confirm the bug, we plan to notify affected third-party services +or software that we know about, prepare an advisory, commit fixes to +the main development branch as quickly as is practical, and finally +publish the advisory on tz(a)iana.org. As with all tzdb contributions, +we give credit to security contributors unless they wish to remain +anonymous. -- 2.27.0

1 1

Wisconsin daylight savings 1957
by TJ April 17, 2021

April 17, 2021

Hey everyone, I was doing some digging and found the following referendum in 1957 for Wisconsin. - https://ballotpedia.org/Wisconsin_Daylight_Saving_Time,_Question_1_(April_1… The text of the measure that passed was: "Shall section 175.095 (2) of the statutes, which proposes a statewide daylight saving time of one hour per day from the last Sunday in April to the last Sunday in September in each year be law beginning with the last Sunday in April 1957?" However, the 1947 ballot to use daylight savings was defeated: https://ballotpedia.org/Wisconsin_Daylight_Saving_Time_Referendum,_Question… In the tz db for North America, it looks like Wisconsin is using America/Chicago which has a few rules for the time period in question: Rule Chicago 1922 1954 - Sep lastSun 2:00 0 S Rule Chicago 1955 1966 - Oct lastSun 2:00 0 S It appears to me that Wisconsin might need some modification? Is this the correct mailing list for this discussion? Thanks, TJ

3 3

Ref: What time is it: managing time in the internet
by Brian Inglis April 17, 2021

April 17, 2021

"What time is it: managing time in the internet", p37–44, July 2019, "Proceedings of the Applied Networking Research Workshop" https://dl.acm.org/doi/10.1145/3340301.3341125 "investigation of how current local time is reported accurately by devices connected to the internet", analysis of tzdb and updates, "proposals for enhancing TZDB management and reducing vulnerabilities in the system." -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]

2 2