May 2021 - tz - lists.iana.org

[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