- tz - lists.iana.org

Destruction of timezone history - please revert
by Alois Treindl June 12, 2021

June 12, 2021

I consider the decision to merge zones of multiple countries, just because they share a common post-1970 history, one of the worst decisions ever made for the TZ project. There used to be Zone Europe/Copenhagen, which represented the exact timezone history of Copenhagen, in fact all of Denmark, since the introduction of standard time in Denmark in 1890. Not the file 'europe' says # For Denmark see Europe/Berlin. But zone Europe/Berlin is a bad representation Denmark's timezone history. It gives false data from 1949 backward. The decision to remove zones like Europe/Copenhagen from the main zone files destroys the work of a whole generation of timezone history researchers. It is a completely unnecessary step, forced by nothing. I urge the responsible persons top revert this step.

1 0

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

June 9, 2021

On 5/20/21 10:50 AM, Kerry Shetline wrote: > Is there a particular reason that the following situation is handled with bespoke awk processing: The goal was to keep the data source simple, and put hacks into ziguard.awk when that's easy. I would rather not have these hacks bleed into the data source. > It would be great if the special comments would be all one needed to parse the data for rearguard, main, or vanguard. I see where you're coming from, but that's not the goal here. I didn't want to invent a preprocessor for zic, creating technology that would have to be documented and supported and have backwards-compatibility problems of its own. The vanguard/main/rearguard stuff is just a hopefully-temporary hack that, once it evaporates, will require zero maintenance. By the way, is anybody still using rearguard format? If not, perhaps it's time to retire this stuff now. (That would save us all the hassle of conversations like this one. :-)

4 7

What data should TZDB offer?
by Stephen Colebourne June 7, 2021

June 7, 2021

TZDB has seen recent difficulties due to conflicting desires and expectations of the dataset. This is an attempt to capture some of these: 1) LMT LMT is confusing for many downstream users because they don't understand the concept. Recent threads have noted queries from Postgres users, I can attest to confusion in various Java libraries. In fact, earlier versions of Java removed the LMT concept. I think the time is right to properly consider an alternative to LMT. I believe we can define an offset for each region that the region has most typically been associated with post 1970. For example, Europe/Paris is most associated with +01:00 since 1970. This provides the "normal looking" offset that most users desire for the LMT period. 2) Negative DST Negative DST in the source files continues to be a problem, but we should address other issues first. 3) Links At present, it is not possible to identify which region names are deprecated (such as spelling changes) and which represent important data. Having such a distinction would allow permanent deprecations to be removed from some downstream systems, and would also allow downstream systems to provide functionality to normalize IDs from old to new in a correct and consistent way. 4) Pre-1970 history There is general, though not compete, agreement that TZDB's main focus is on post-1970 data. However I and others have an expectation that pre-1970 data is retained and not be removed. I don't want to get into a position where pre-1970 history is basically completely unreliable relative to the name of the ID. Getting Germany's pre-1970 rules when you have an ID for Oslo or Sweden is not acceptable. (We already have some of that, but the recent proposal would have greatly increased the issue. I feel that there is the potential to achieve an agreeable solution, but it does require acceptance that full pre-1970 history is needed for some places that have the same zone history post-1970. 5) Compatibility guarantee Changes need to be made with more consideration of the implications of compatibility on downstream users that do not use the makefile. Proposal ------------ That TZDB shall adopt the principle that the main geographic files (africa to southamerica) shall contain data with full history for locations where zone history has differed since 1970 subject to the minimum requirement that there is at least one full zone with history defined for each independent country as defined by ISO-3166-1. Dependent territories in ISO-3166-1 that are within 1/24th of the earth circumference of another dependent territory or parent country with the same sovereignty shall be combined if their post-1970 history is identical. That TZDB shall replace LMT with the offset that best represents standard time for the location during the period 1970 to 2021. That TZDB shall define a non-makefile mechanism, which may involve a new file, to identify permanently deprecated IDs, such as "Turkey" or "W-SU". That TZDB shall offer a command line makefile flag that filters the data to reduce the binary output where data is the same post-1970. That consideration is given to whether this flag should erase pre-1970 history as part of it's truncation process. That these rules shall be encoded in the theory file along with an explicit statement of backwards compatibility. ----- It is my belief that this proposal meets the issues expressed above while also respecting the concerns of fairness, guidelines and politics expressed by others. For example, TZDB would not include a full zone with history for Kosovo until ISO-3166-1 includes it. This provides a straightforward defence against the worst issues of politics. The dependent territory rules are designed to allow locations that are close to each other in distance and sovereignty to be combined, such as Jersey and London. I have not analyzed how many zones of full history can be saved by this mechanism. I acknowledge that the above is a significant change to TZBD, but it does more fully align TZDB with the Governmental authorities that actually define time zones. I also believe it more closely aligns TZDB with the expectations of downstream users. Stephen

13 25

[PATCH] Update Android URL on tz-link page
by Almaz Mingaleev June 7, 2021

June 7, 2021

The APK-based time zone date update mechanism was deprecated so the current link to Play Store is misleading. The new link gives relevant information and is kept up-to-date.

1 0

Breach of tzdb charter: Merging timezones is not within the charter
by Stephen Colebourne June 4, 2021

June 4, 2021

This is a formal request to revert the recent patch to merge country timezones. I, and others, consider the patch to be utterly unacceptable. The patch causes meaningful harm to the status of tzdb, and will cause downstream projects significant pain to effectively revert the changes - amounting to an effective fork of the project. Specifically, the patch merges the timezone history of completely separate countries, effectively wiping places like Norway and Sweden off the map to replace them by Germany. (Many other countries are also proposed to be wiped off the map). The reversion MUST occur as soon as possible, and MUST be before the next tzdb release. The tzdb coordinator is expected to operate by this charter: https://datatracker.ietf.org/doc/html/rfc6557 """ The TZ Coordinator is empowered to decide, as the designated expert, appropriate changes, but SHOULD take into account views expressed on the mailing list. ... The criteria for updates to the database include the following: 1. New TZ names (e.g., locations) are only to be created when the scope of the region a name was envisioned to cover is no longer accurate. 2. In order to correct historical inaccuracies, a new TZ name MAY be added when it is necessary to indicate what was the consensus view at a given time and location. Such TZ names are usually not added when the inaccuracy was prior to 1970. 3. Changes to existing entries SHALL reflect the consensus on the ground in the region covered by that entry. To be clear, the TZ Coordinator SHALL NOT set time zone policy for a region but use judgment and whatever available sources exist to assess what the average person on street would think the time actually is, or in case of historical corrections, was. """ I contend that to date, the TZ coordinator has not actively shown any serious willingness to accept that the proposed changes are unacceptable to a significant segment of tzdb users. As such, the coordinator has not taken into account the views of the mailing list. I also contend that the "cleanup" being proposed is not within the charter of the project. Point 1 refers to new zones, thus is not applicable. Point 2 refers to correcting historical inaccuracies, yet it is clear that the proposed change *adds* historical inaccuracies. Point 3 refers to changes, but only in terms that reflect what people in the relevant location would have considered the time zone to have been, yet clearly the proposed change does not do that. No part of the charter permits the coordinator to willfully harm the database, nor to merge timezone regions, nor to increase the number of historical inaccuracies. Justifications for the proposed change based on "consistency" or "politics" are not rooted in the charter of tzdb and should be considered null and void. Given the above, I contend that the actions of the tzdb coordinator are in breach of the charter of the project, I therefore request that the changes are reverted immediately. Stephen Colebourne

13 17

New JavaScript/Node.js timezone compiler
by Kerry Shetline June 4, 2021

June 4, 2021

https://github.com/kshetline/tubular_time_tzdb I spoke about this new tz compiler a while back, when I released my @tubular/time date-time library, but the compiler was only at the level of a tool for personal use, without decent documentation or all of the features I’d want for a general-purpose utility. At first this compiler only produced data for use with @tubular/time, but now it can output zoneinfo/zic binaries too. One nice feature is that this tool, by default, reaches right out to https://www.iana.org/time-zones/ for data, with no need to download a release before using the compiler. There’s a JavaScript/TypeScript API and a CLI command. I’ll show the CLI command help, just so people can get an idea of the options available. Anyone can go to https://github.com/kshetline/tubular_time_tzdb for more info. npm install -g @tubular/time-tzdb Usage: tzc [options] [output_file_name_or_directory] Downloads and compiles IANA timezone data, converting to text, zoneinfo binary files, or @tubular/time-compatible data. Options: -v, --version output the version number -5, --systemv Include the SystemV timezones from the systemv file by uncommenting the commented-out zone descriptions. -b, --binary Output binary files to a directory, one file per timezone -B, --bloat Equivalent to the zic "--bloat fat" option. -f Filter out Etc/GMTxxx and other timezones that are either redundant or covered by options for creating fixed-offset timezones. -i Include leap seconds in binary files. -j, --javascript Output JavaScript instead of JSON. --large Apply presets for "large" timezone definitions. --large-alt Apply presets for "large-alt" timezone definitions. --list List available tz database versions. -m Round all UTC offsets to whole minutes. -n, --no-backward Skip the additional aliases in the backward file. -o Overwrite existing file/directory. -q Display no progress messages, fewer warning messages. -R, --rearguard Rearguard mode (skip vanguard features like negative DST). -r Remove 'calendar rollbacks' from time zone transitions -- that is modify time zone data to prevent situations where the calendar date goes backwards as well as the hour and/or minute of the day. -p, --packrat Add additional timezones from the backzone file. -s <zone-id> ID/name for a single timezone/region to be rendered. --small Apply presets for "small" timezone definitions. -t, --typescript Output TypeScript instead of JSON. --text Output (somewhat) human-readable text -u, --url <url> URL or version number, such as '2018c', to parse and compile. Default: https://www.iana.org/time-zones/repository/tzdata-latest.tar.gz -V, --vanguard Vanguard mode (use vanguard features like negative DST). -y <year-span> <min_year,max_year> Year range for explicit time zone transitions. Default: 1850,2050 -z <zone-info-dir> Validate this tool's output against output from the standard zic tool stored in the given directory. (Validation is done before applying the -r option.) -h, --help display help for command -, Use dash by itself to output to stdout.

2 1

Demetrios Matsakis of USNO on NPR
by Steve Allen June 2, 2021

June 2, 2021

Today NPR has a 2 minute musical interview about daylight time with Demetrios Matsakis of USNO https://www.npr.org/2021/06/02/1002368937/an-expert-has-the-answers-to-dayl… -- 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

2 1

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