Stephen Colebourne via tz <tz@iana.org> writes:

On Mon, 20 Sept 2021 at 11:48, Eliot Lear via tz <tz@iana.org> wrote:

...

I would suggest an alternative: the policy of this group is set in an RFC, and that RFC can be updated if there is consensus in this community to do so. If the community doesn't like the policy, it can change it, and continue to gain the benefit of one another.

Right now there is effectively a schedule gun being held to our heads - if we do not act a new release will come out with the disputed changes in it.

Indeed, and at that point it would pretty much be a fait accompli, because reverting the changes later would create an even huger mess. As far as the RFC (BCP 175) goes, I'll just quote it:

...

5. Appealing Database Decisions

The TZ Coordinator makes decisions based on expertise, as well as with guidance from the TZ mailing list. If a member of the community has a concern with an individual decision made by the TZ Coordinator with regard to the TZ database, the individual shall proceed as follows:

1. Attempt to resolve the concern directly with the TZ Coordinator.

2. If a resolution cannot be reached directly with the TZ Coordinator, express the concern to the community and attempt to achieve rough consensus regarding a resolution on the TZ mailing list. The Area Directors of the IETF Applications Area may at their discretion attempt to guide the members of the community to rough consensus.

3. As a last resort, if a resolution cannot be reached on the TZ mailing list, appeal to the IESG for a resolution. The appellant must show that the decision made by the TZ Coordinator (a) was materially in error and (b) has caused material harm. In its deliberations regarding an appeal, the IESG shall weigh all the evidence presented to it and use its best judgment in determining a resolution.

Seems to me that we have failed at step 1, and that to the extent that there is any community consensus per step 2, it is against this set of changes. So per process we ought to move on to step 3. (This should have been done months ago, likely, but everyone was hoping for a less unfriendly outcome.) The problem now is that there is no time for any such appeal. We need 2021b now, and if it comes out with these changes, the only way for people to retain stability of the data is to fork. (I suppose for a lot of us, the least painful choice is to sit on 2021a for awhile, ignoring the Apia changes.) regards, tom lane

On Mon, 20 Sep 2021, Clive D.W. Feather via tz wrote:

Tom Lane via tz said:

...

...

...

2. If a resolution cannot be reached directly with the TZ Coordinator, express the concern to the community and attempt to achieve rough consensus regarding a resolution on the TZ mailing list. The Area Directors of the IETF Applications Area may at their discretion attempt to guide the members of the community to rough consensus.

...

Seems to me that we have failed at step 1, and that to the extent that there is any community consensus per step 2, it is against this set of changes.

I'm not convinced that there is even that much consensus. We're hearing from the objectors, but - as usual - not from those who approve or aren't affected. I'm currently unclear what the issues are, being mostly an observer rather than a significant user of the database.

I think I fall into the class of users which you labelled "aren't affected" although the adverb "directly" might be missing, since to some degree the whole world is afffected! My contribution count to tzdb is - barely - larger than zero, so I'm not a total lurker! And I am a member of the NetBSD developer community, where tzdb is included in the base software distribution. (HOWEVER, I am writing this note as an individual, and not on behalf of NetBSD.) I personally don't have a horse in this race, and either revert or not-revert works for me. If I had to lean in one direction, I'd probably lean towards reverting, and thus returning to something closer to historical conventions. However, if a split/fork were to happen, I'd certainly follow the "original" fork, while perhaps browsing the "divergent" fork now and then just to monitor the situation. Any attempt I'd be inclined to further contribute would be directed at the original fork. Overall, I think a fork of tzdb would be harmful to the community at large, but I really have no other practical alternatives to suggest for resolving the conflict. So, +1 for the approve-or-not-affected category! +--------------------+--------------------------+----------------------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | paul@whooppee.com | | Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette@netbsd.org | | | | pgoyette99@gmail.com | +--------------------+--------------------------+----------------------+

On 9/20/21 10:18 AM, Derick Rethans via tz wrote:

Who asked for historical information to be unavailable from the default tzdb distribution?

In June, Stephen Colebourne suggested that as an acceptable solution: https://mm.icann.org/pipermail/tz/2021-June/030273.html and yesterday wrote that he'd still have more respect for that approach than for what's currently in the development database: https://mm.icann.org/pipermail/tz/2021-September/030421.html However, this would be a bigger change to tzdb than other proposed suggestions. Although it wouldn't affect all that many uses (none of the proposed changes do) I expect it would be even less popular than the other proposals.

On Mon, Sep 20, 2021 at 8:52 AM Stephen Colebourne via tz <tz@iana.org> wrote:

On Mon, 20 Sept 2021 at 11:48, Eliot Lear via tz <tz@iana.org> wrote:

...

I think it's a bad idea to fork for a great many reasons, only a few of which are the following:

Time confusion going forward, with new inconsistencies being introduced. Implementer confusion in terms of which code base is more up-to-date; worse if the code base fragments. Fragmentation of expertise among volunteers

I fear that you drastically underestimate the effort that has been required to maintain both the code and the data.

If you read carefully, my original mail proposed forking the data - it did not propose forking the code. I imagine this would be a case where the fork would follow each commit in tzdb, including the code changes, but seeking to maintain the data set as it should be.

Speaking as a participant only: I agree with Eliot. Though I'm a relative newcomer to this particular space, I have never seen a successful fork of the nature you're describing. You make it sound simple here, but I would bank on the inevitability of some change being introduced into the original data that cannot be trivially merged into the fork. I wouldn't want to be the person responsible for sorting that out while simultaneously tracking all of the other issues the current coordinator handles on a regular basis. -MSK

On 9/20/21 6:52 AM, Derick Rethans via tz wrote:

So will the PHP project.

With the patches I emailed in <https://mm.icann.org/pipermail/tz/2021-September/030456.html>, the PHP project should be able to avoid the effects of the alike-since-1970 patches without our having to fork tzdb, by using something like the attached (untested) patch to PHP's timelib. However before taking such an approach, please read the comments of the bias2021a.bp file, which suggest that you'll need to adjust that file. For more, please see my other recent email <https://mm.icann.org/pipermail/tz/2021-September/030458.html>.

On Sep 20, 2021, at 11:06, Emily Crandall Fleischman via tz <tz@iana.org> wrote:

I personally am ambivalent about the changes in question, and overall have very little stake in this, but I would hate to see such drastic action as a fork taken before all other avenues have been exhausted.

++ Cheers! |---------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |---------------------------------------------------------------------| | A room without books is like a body without a soul. | | | | -- Cicero | |---------------------------------------------------------------------|

Paul Eggert via tz <tz@iana.org> writes:

On 9/20/21 1:06 AM, Stephen Colebourne via tz wrote:

...

...

These have the effect of wiping out historic time-zone information on many locations where the data has been in tzdb for many years.

None of the information has been "wiped out". It has merely moved from one source file to another, and builds with PACKRATDATA=backzone still install all the info in question. This disagreement is not about "wiping out" info; it's about what category the info falls into.

The concern I'm having is that according to experiments I did back in June, the above is not true. As far as I can tell, adding PACKRATDATA=backzone does *not* reproduce what was formerly the default set of zones. I'm all for improving equity in tzdb's coverage, but I think it should be done by adding coverage for underserved areas, not removing data from areas that had been well-covered. And let's make no mistake: removing data from the default build is removing data, for many downstream users who won't have an opportunity to make their own decisions about what their platforms provide. regards, tom lane

On 9/20/21 11:04 AM, Paul Eggert via tz wrote:

If it's important for PostgreSQL to get data that exactly matches 2021a (except for changes you don't object to), I suggested in <https://mm.icann.org/pipermail/tz/2021-June/030197.html> adding a build-time option to let projects like PostgreSQL choose whatever 'backzone' data they want, instead of 'backzone' being an all-or-nothing decision as it is now. This would let these projects avoid the objected-to changes

Attached is a proposed implementation of this suggestion. The idea is to make it easy for projects like PostgreSQL to act as if the recent alike-since-1970 changes had not occurred, without having to fork tzdb. To try this out in PostgreSQL, you can copy the attached file tzdata.zi to postgres/src/timezone/data/tzdata.zi. This tzdata.zi file contains the other post-2021a changes; just not the alike-since-1970 changes. To generate this tzdata.zi file automatically from the tz main branch, you can do the following: 1. Apply the attached patches to tzdb's current main branch. 2. Save the attached file bias2021a.bp. 3. Run the following shell command: make BACKPICK=bias2021a.bp PACKRATDATA=backzone tzdata.zi The file bias2021a.bp is a "backpick" file that says which Zones and Links should be picked out from the file 'backzone', overriding the other data. bias2021a.bp's comments contain more description. As I hope the comments make clear, this bias2021a.bp file is intended only as a demonstration; the PostgreSQL developers can and should tailor it to fit their needs and project goals. My idea is to apply the attached patches to the tzdb main development branch, with the PostgreSQL developer choosing whatever .bp file they like. Comments welcome.

On 9/20/21 11:03 AM, Stephen Colebourne via tz wrote:

I also believe that discriminating against countries like Angola and Niger is unacceptable. But the solution to that is the same as it always has been - to include full data for each ISO country, using best efforts for data that is not certain.

I addressed this issue toward the end of my recent email to Tom Lane <https://mm.icann.org/pipermail/tz/2021-September/030422.html>, which I sent about the same time you sent your email.

The *only* good faith move you can make right now is to revert the patch.

We disagree on this point. This morning I made a different good-faith move, by installing the "Revert May patch to zone.tab" patch into the development database. I suggested another potential good-faith move in that recent email to Tom Lane. I continue to think that it would be better to work together to find a common solution, than to insist on one unalterable position.

The approach you argue for arbitrarily discriminates too, saying that Germany is more important than Norway or Sweden.

The guideline is not arbitrary; it chooses the most-populous city, in this case Berlin. Although every guideline has a bias of some sort, it would be a quite a stretch to say that this particular guideline has racial, ethnic or national bias, which is the concern here.

Quoting Derick Rethans via tz on Monday September 20, 2021:

I've also not seen any response to the formal complains that were sent to IANA.

To clarify on this, I am not aware of any pending complaints that have been sent to IANA. We host this community project in accordance with RFC 6557, which means that the TZ coordinators are appointed by the IESG, and also the appeals process is operated by them <https://www.ietf.org/about/groups/iesg/>. I understand there is an appeal pending that is being considered by the IESG. <https://mm.icann.org/pipermail/tz/2021-June/030308.html> Importantly, this is a community project and the intention is for consensus to be built in this very forum for changes to be made, and IANA does not play a role in editorial decisions concerning timezones.

I don't like the idea of a fork, mostly because it serves nobody to have two competing versions of tzdb, but right now I can't see another way out...

I agree that forking this work leaves everyone the poorer, I hope a resolution can be found that is satisfactory to everyone. kim

To me this looks like a fork whether another repository is created or not. With multiple down stream database parsers (as is the case for C++ vendors, and other languages as well), each vendor is going to make a choice as to include backzone or not. Today the choice is obvious: don’t include, because: * there’s not much in it. * the comments in the file discourage its use. * It has different parsing rules than africa, asia, europe, etc. By putting more data into backzone, this greatly increases the odds that some vendors are going to adopt backzone, and other’s won’t. That’s a fork. ************** I would instead like to see a move in the opposite direction: Consolidation to a single accepted version of the data, even if flawed, that slowly gets better as time goes on. Howard On Sep 21, 2021, at 1:03 AM, Eliot Lear via tz <tz@iana.org> wrote:

You have but a compiler flag to add, but instead you want to fork?

Ok. That'll be fun when I get one time from the OS and one time from PHP when the update policies diverge – and you can bet they will.

Yes, please.  It will create less messes over time. On 21.09.21 16:08, Tom Lane via tz wrote:

...

I would instead like to see a move in the opposite direction: Consolidation to a single accepted version of the data, even if flawed, that slowly gets better as time goes on. +1

Paul Eggert <eggert@cs.ucla.edu> writes:

On 9/21/21 7:08 AM, Tom Lane via tz wrote:

...

if any significant number of vendors start including backzone to restore some approximation of the way things stood before, then there is going to be the same mess from end users' standpoint as a true fork would produce.

True, and a good reason to not make use of the draft patches that I emailed earlier today in <https://mm.icann.org/pipermail/tz/2021-September/030456.html>.

Yeah, I was about to reply to that along similar lines: I think we should put some value on most people using the same version of tzdb, so adding options to pick-and-choose subsets of the data is arguably counterproductive.

There's another good reason to not use that approach, noted in the bias2021a.bp file in that email:

# This file should be not be used in production by organizations # committed to equity, diversity, and inclusion because it restores # the previous tzdb setup, which arguably exhibited racial or national # preferences.

TBH, I find that argument to have just about zero merit. It's not like the previous state of affairs was deliberately non-diverse, nor do I believe that the May patches magically removed all potential complaints of that sort. I think the way to proceed here is what has been suggested by several people including me: revert to the pre-May set of zone data, and make a commitment that we'll accept properly-researched patches to add per-country zones over time. (This need not be a commitment that the TZ Coordinator would do such research.) I think the reason that e.g. Norway has its own zone is that somebody did the research to add it once upon a time. Why should we devalue that effort now? regards, tom lane

On 9/20/21 11:53 AM, Derick Rethans wrote:

Stephen tried many months ago to come up with a set of statements and suggestions to come up with a reasonable policy on what to do, and although there were some issues with that, there was at least an attempt to codify a way forwards.

Although there were definitely issues, we could reopen that discussion. Eliot Lear also suggested something along those lines. As I recall quite a few words were exchanged but the details are fuzzy in my mind. To help narrow things down, it'd be helpful to propose a specific patch to theory.html. (theory.html is the file that contains the guidelines in question.) You'd surely need such a patch anyway if you fork. And now's a good time to write the patch, if only to justify why a fork is necessary. However, I hope the exercise of writing the patch can help us find a way to avoid the fork.

   On 2021-09-20 20:56, Stephen Colebourne via tz wrote:

I have always wanted the first option - forking is not a good outcome.

   I propose not to fork tzdb and instead revoke the proposed    changes until we can agree on a *complete* picture of how the    changes can be effected without inducing undue burdens on any    downstream user. Fixing singular aspects of the proposed    change does not seem to suffice in this situation.    We know one possible solution, proposed by Stephen Colebourne    (but others might be worth considering as well):    ∙ the main line data of tzdb should contain all the historical      data we have, and SHOULD be maintained as such;    ∙ there are options to reduce the amount of historical data by      merging timezones with links and/or by stripping old      transitions from timezone data; such options MAY be added      if necessary;    ∙ using zic with the same options on successive versions of      tzdb data SHOULD not lead to major changes in the scope      and structure of the TZif results;    ∙ similarly, for those using the tzdb data directly, the      organization of tzdb data into files SHOULD not change      significantly across successive versions.    For instance, the proposed merge of timezones agreeing since    1970 can be done quite simply with a new file with links    (such as merge1970) without affecting users who cannot    use the merge.    Michael Deckers.

On 9/20/21 1:56 PM, Stephen Colebourne via tz wrote:

where we disagree is the need to nuke what we have now as a first step.

Again, nothing has been nuked. Some data have merely moved from one place to another.

As I've said before, there are only two equitable solutions for the default tzdb files (ie minus backzone). Either they contain full history for every ISO country (even if that history is inaccurate), or they contain no pre-1970 data at all.

There's no need to involve ISO countries, as far as equity is concerned. Suppose someone argued that there should be a full timezone history for every state and province and city in the world, and that otherwise there should be no pre-1970 data at all. Such an argument would be equally invalid, even though these smaller entities were (and in many cases still are) the governmental agencies responsible for setting civil-time rules. For proper timekeeping we needn't model every governmental agency involved in timekeeping; all we need to do is model the timekeeping. Requiring involvement of countries complicates the TZ database for political reasons, not for timekeeping reasons. As such, it complicates maintenance, mostly due to political hassles. We do better by avoiding political entanglements when possible.

Expecting downstream projects to change their build systems with no notice to solve an artificially created crisis isn't good project management.

Yes, it would be better if we came to a consensus and did not have to fork the repository or fork the project in some other way. Any such fork will require some sort of build-system changes for those who doesn't take the default approach. As I've tried to make clear in my recent emails, although the proposed fork is technically feasible (and doesn't even need to rely on a copied repository), it's not a good idea. This is not merely because of the hassle of configuring after a fork; it's because merely going back to 2021a's setup is not something we can or should do, on equity grounds.

On 9/20/21 2:58 PM, Robert Elz wrote:

If someone in (or from) Angola or Niger wants th research their timezone history, and send it, it should be included, just like that for the US,

Yes, and there's a place for that in 'backzone'. We're not refusing timezone history because it's unnecessary due to the alike-since-1970 rule. It's put into 'backzone' and is welcome there. Perhaps some people have the misimpression that we have many potential contributors whose data are being refused. On the contrary, almost nobody contributes historical data, because it's boring unpaid work and honestly, it's not that important. I know that, because I contributed the vast majority of 'backzone' (a contribution that I'm coming more and more to regret :-). This disagreement is not about whether the data in question are available; it's only about which file they're in. Nothing is being "wiped out" or refused.

I've always believed that there should be at least one zone for every time zone authority on the planet

That would be ideal, and I hope something like that would be doable for current and future timestamps. But it'd be a stretch to try to do it for all timestamps since 1970, and it'd be completely impractical for pre-1970 timestamps. We don't know who the historical time zone authorities were, much less what rules they used.

The only real cost is a little extra processing time generating the zones, and a trivial amount of zone data files.

I think this greatly underestimate the effort to do a complete job. We'd eventually need thousands of Zones. I expect we'd have to revamp the underlying technology too, and do something more like what Shanks evidently did (though I haven't seen his source code). I would not consider that trivial, and I think our collective effort would be better spent elsewhere.

On 9/21/21 12:33 PM, Stephen Colebourne via tz wrote:

The current unreleased state of tzdb is that it favours some countries over others, such as Germany over Sweden/Norway.

It also "favors" some states over others, such as Arizona (which has the America/Phoenix Zone) over Utah (which has no Zone). It's the same argument, and it's an equally invalid argument as far as timekeeping goes. That sort of argument would be valid only if one accepted as an axiom that countries (or states) are an inherent part of timekeeping. But we don't need to take that as an axiom, and tzdb has done well to avoid nation-state political entanglements as much as possible.

On 9/21/21 12:47 PM, Garrett Wollman wrote:

...

That sort of argument would be valid only if one accepted as an axiom that countries (or states) are an inherent part of timekeeping. Governments self-evidently are: they are why we even have time zones in the first place.

Of course governments determine civil-time rules, and these rules determine what goes into tzdb. But that does not mean that tzdb must include Zones for Utah, Idaho, Montana etc. merely because Arizona has an Zone. All it means is that we need to record governmental rules accurately and concisely. tzdb will continue to be easier to maintain and use if it focuses on timekeeping, not politics.

On 9/21/21 1:20 PM, Stephen Colebourne via tz wrote:

Straw man. Literally no one has suggested this.

Yes, of course it's a straw argument. That's the point. Although it'd be technically possible to require a Zone for each state and province in the world, it's not necessary, it would consume maintenance resources that are better spent elsewhere, and Zone proliferation would make things unnecessarily complicated for users. The situation for countries is similar. Admittedly there are few countries than states+provinces, but logically there's no difference between the two cases.

If you don't like ISO countries as the basis of a rule, feel free to suggest something else.

My suggestion is to stick with the rules already in theory.html. They've worked well over the years.

If you want to resolve the issue you need a rule that doesn't end up with users in Norway or Sweden requesting the time-zone for 1950 and getting the zone information of Germany instead.

If that's the idea, then I also need a rule that doesn't end up with users in Munich requesting the time zone for September 20, 1945 and getting the UTC offset of Berlin instead. The case for a Munich Zone is even stronger than the case for an Oslo Zone, as Munich has a lot more people (and more tzdb users) than Oslo does. Of course this is a straw argument too; that's the point. All this stuff about pre-1970 timestamps is out of scope for tzdb proper, and it's always been out of scope. Only politics would require us to have a Zone for every ISO country. Timekeeping needs don't require it. Admittedly we used to have more Zones, but we've never had a Zone for every ISO country and no timekeeping need for such a rule has ever been demonstrated.

Stephen Colebourne via tz said:

...

Admittedly there are few countries than states+provinces, but logically there's no difference between the two cases.

Of course there is. A 10 year old could explain the difference between a state and a country.

Go ahead, then. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

dpatte via tz said:

...

Only politics would require us to have a Zone for every ISO country. Timekeeping needs don't require it. Admittedly we used to have more Zones, but we've never had a Zone for every ISO country and no timekeeping need for such a rule has ever been demonstrated. Perhaps current timekeeping does need it, but historical time based research does, and that is our point.

Which is why you have the choice of 1970-onwards or everything-we-know. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

Sent from my GalaxyEzactly, which is why tz must use iso countries in its specification.Anything less than accepting iso countries, and continuing to use tz countries is nothing but a tz attempt to apply it's own political decisions on others.Iso has that mandate, not tz.   tzdb will continue to be easier to maintainand use if it focuses on timekeeping, not politics.

On Tue, Sep 21, 2021 at 12:48 PM Garrett Wollman via tz <tz@iana.org> wrote:

<<On Tue, 21 Sep 2021 12:44:22 -0700, Paul Eggert via tz <tz@iana.org> said:

...

That sort of argument would be valid only if one accepted as an axiom that countries (or states) are an inherent part of timekeeping.

Governments self-evidently are: they are why we even have time zones in the first place. Everything in this database is _inherently_ political, and your continued attempts to "avoid politics" do nothing of the sort.

If what we want is one time zone per country, let's have that conversation instead of having it happen by accident as a side effect of rules that don't mention countries. Sincerely, Watson Ladd

-GAWollman

And who gets to decide?  The strategy used over the entire existence of this database has obviated the need to answer that question. Eliot On 21.09.21 22:07, Clive D.W. Feather via tz wrote:

Watson Ladd via tz said:

...

If what we want is one time zone per country, let's have that conversation instead of having it happen by accident as a side effect of rules that don't mention countries. I agree.

But, if we want to talk about countries, what would surely be more useful is a list, for each country, of all the time zones that are at least partially in that country.

Oh, please define "country". Is England a country? Wales? The Netherlands (as opposed to the Kingdom of the Netherlands)? Sealand? Taiwan? Macau? Bir Tawil? Liberland?

Do you really want to open this can of worms?

On Tue, Sep 21, 2021 at 3:42 PM dpatte <dpatte@relativedata.com> wrote:

The strategy used since tz was created has caused many political arguments and decisions in this group instead of deferring the decisions to the ISO that has this mandate.

ISO countries doesn't solve some of the thorny political issues, because ISO codes don't take a position on boundary disputes or naming disputes. E.g. Crimea. When the invasion happened, the civil time in the region occupied changed. That means a new zone entry needed to be created. I don't know how defering to ISO resolves the naming of that one. The other example would be Palestine. Regardless of what ISO decides, the time in Palestine is what it is, and is different from Israel in funny ways, and the territories that have gone back and forth have gone back and forth and thus need new entries. What ISO countries do solve is the vanity issues of people wanting timezones with their local big cities in them appearing in a list, even if the timezone is the same as one in another country. Sincerely, Watson Ladd

Sent from my Galaxy

-------- Original message -------- From: Eliot Lear via tz <tz@iana.org> Date: 2021-09-21 16:17 (GMT-05:00) To: "Clive D.W. Feather" <clive@davros.org>, Watson Ladd <watson@cloudflare.com> Cc: tz <tz@iana.org> Subject: Re: [tz] Preparing to fork tzdb

And who gets to decide? The strategy used over the entire existence of this database has obviated the need to answer that question.

Eliot

On 21.09.21 22:07, Clive D.W. Feather via tz wrote:

...

Watson Ladd via tz said:

...

If what we want is one time zone per country, let's have that conversation instead of having it happen by accident as a side effect of rules that don't mention countries. I agree.

But, if we want to talk about countries, what would surely be more useful is a list, for each country, of all the time zones that are at least partially in that country.

Oh, please define "country". Is England a country? Wales? The Netherlands (as opposed to the Kingdom of the Netherlands)? Sealand? Taiwan? Macau? Bir Tawil? Liberland?

Do you really want to open this can of worms?

Incorrect..Iso 3166Ramallah is recognized in the State of Palestine.Sevastopol is recognized as a city as being in Ukraine.If you disagree politically, you can raise your issue with the iso.Sent from my Galaxy -------- Original message --------From: Watson Ladd <watson@cloudflare.com> Date: 2021-09-21 18:49 (GMT-05:00) To: dpatte <dpatte@relativedata.com> Cc: Eliot Lear <lear@lear.ch>, "Clive D.W. Feather" <clive@davros.org>, tz <tz@iana.org> Subject: Re: [tz] Preparing to fork tzdb On Tue, Sep 21, 2021 at 3:42 PM dpatte <dpatte@relativedata.com> wrote:>>> The strategy used since tz was created has caused many political arguments and decisions in this group instead of deferring the decisions to the ISO that has this mandate.ISO countries doesn't solve some of the thorny political issues,because ISO codes don't take a position on boundary disputes or namingdisputes. E.g. Crimea. When the invasion happened, the civil time inthe region occupied changed. That means a new zone entry needed to becreated. I don't know how defering to ISO resolves the naming of thatone.The other example would be Palestine. Regardless of what ISO decides,the time in Palestine is what it is, and is different from Israel infunny ways, and the territories that have gone back and forth havegone back and forth and thus need new entries.What ISO countries do solve is the vanity issues of people wantingtimezones with their local big cities in them appearing in a list,even if the timezone is the same as one in another country.Sincerely,Watson Ladd>>>> Sent from my Galaxy>>> -------- Original message --------> From: Eliot Lear via tz <tz@iana.org>> Date: 2021-09-21 16:17 (GMT-05:00)> To: "Clive D.W. Feather" <clive@davros.org>, Watson Ladd <watson@cloudflare.com>> Cc: tz <tz@iana.org>> Subject: Re: [tz] Preparing to fork tzdb>> And who gets to decide?  The strategy used over the entire existence of> this database has obviated the need to answer that question.>> Eliot>> On 21.09.21 22:07, Clive D.W. Feather via tz wrote:> > Watson Ladd via tz said:> >> If what we want is one time zone per country, let's have that> >> conversation instead of having it happen by accident as a side effect> >> of rules that don't mention countries.> > I agree.> >> > But, if we want to talk about countries, what would surely be more useful> > is a list, for each country, of all the time zones that are at least> > partially in that country.> >> > Oh, please define "country". Is England a country? Wales? The Netherlands> > (as opposed to the Kingdom of the Netherlands)? Sealand? Taiwan? Macau?> > Bir Tawil? Liberland?> >> > Do you really want to open this can of worms?> >>>

On Sep 21, 2021, at 4:51 PM, dpatte via tz <tz@iana.org> wrote:

Date: 2021-09-21 18:49 (GMT-05:00) To: dpatte <dpatte@relativedata.com> Cc: Eliot Lear <lear@lear.ch>, "Clive D.W. Feather" <clive@davros.org>, tz <tz@iana.org> Subject: Re: [tz] Preparing to fork tzdb

...

On Tue, Sep 21, 2021 at 3:42 PM dpatte <dpatte@relativedata.com> wrote:

...

The strategy used since tz was created has caused many political arguments and decisions in this group instead of deferring the decisions to the ISO that has this mandate.

ISO countries doesn't solve some of the thorny political issues, because ISO codes don't take a position on boundary disputes or naming disputes. E.g. Crimea. When the invasion happened, the civil time in the region occupied changed. That means a new zone entry needed to be created. I don't know how defering to ISO resolves the naming of that one.

The other example would be Palestine. Regardless of what ISO decides, the time in Palestine is what it is, and is different from Israel in funny ways, and the territories that have gone back and forth have gone back and forth and thus need new entries.

Incorrect..

Iso 3166

Ramallah is recognized in the State of Palestine.

And Hebron, presumably - it's the city used for West Bank Palestine.

Sevastopol is recognized as a city as being in Ukraine.

But it's not a city used for a tzdb - Simferopol is. And Kyiv is also a city in Ukraine, but, as far as I know, it keeps different time from Simferopol, and the tzdb recognizes that. However, "deferring to ISO" doesn't mean "providing one *and only one* tzdb region per ISO country"; such a policy would not work very well for the three largest countries listed in the northamerica file, for example. If, indeed, Crimea and the rest of Ukraine do not, in practice, keep the same time, then, hopefully, "deferring to ISO" also wouldn't mean "giving Crimea the same offset and rules as the rest of Ukraine".

dpatte via tz <tz@iana.org> writes:

I certainly never sugested that. In fact quite the opposite. But I believe there should be AT LEAST one zone per iso country, and it was the removal of the Montreal historical data a few years back that got me started.

It's frustrating when people keep saying things like this given that no data has been removed. I am literally looking at it right now in the GitHub repository. It's right there. It becomes hard to tell if people are genuinely confused about this, if "removed" is shorthand for "my operating system stopped including that zone," if "removed" means "I find it difficult to access now," or if it's a rhetorical device to make the changes sound more severe and destructive than they actually were to people who don't understand the true situation. But it's simply not true as stated.

Up until recently some of this data was available in the main tz file. We need that back, with the ability to expand and improve it.

I don't understand what you think is preventing you from expanding and improving that data literally right now. My understanding is that Paul has said multiple times that if someone wants to do the thankless and tedious reserach to find more accurate historical data with references, patches will be reviewed and integrated. Am I misremembering somehow? I completely understand that you are not happy with the default build choices or with the set of data that's shipped with major operating systems, and I'm not saying that you have nothing to be unhappy about. But I think it would lead to more constructive discussion if we could describe the situation accurately and without exaggeration, and not claim that data was deleted when it is still included in every release of tzdata. -- Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

On 2021-09-23 12:29:06 (+0800), dpatte via tz wrote:

I am aware that montreal was moved to back zone because its post 1970 data after research turned out to match toronto.But I have yet to get a clear answer as to whether we can request modifications to backzone records even if they only affect pre1970 clocks, and whether we can add new backzones for regions that differ before 1970. 

Changes are routinely made to backzone, backed up with verifiable documentation and commentary. https://github.com/eggert/tz/commits/main/backzone Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises

Clive D.W. Feather via tz <tz@iana.org> wrote:

Oh, please define "country".

Jon Postel deftly answered that question in the 1980s by deferring to ISO 3166, and so far all the concrete suggestions for the tz database have followed his lead. Tony. -- f.anthony.n.finch <dot@dotat.at> https://dotat.at/ North Utsire: Southwesterly 3 to 5, increasing 6 or 7, veering westerly 3 or 4 later. Moderate or rough, becoming rough later, occasionally very rough later in far north. Rain later. Good, occasionally moderate later.

Clive D.W. Feather <clive@davros.org> wrote:

Tony Finch said:

...

...

Oh, please define "country". Jon Postel deftly answered that question in the 1980s by deferring to ISO 3166,

Except that [...]

I don't think anyone is claiming it is perfect, just that it is the best list available: it is familiar, widely used in Internet standards, reasonably well maintained, and other people are responsible so we don't have to fuss about it. Tony. -- f.anthony.n.finch <dot@dotat.at> https://dotat.at/ Humber, Thames: West or southwest 3 or 4, increasing 5 or 6 later. Smooth or slight becoming slight or moderate. Mainly fair. Good.

Iso is a living international standard, and it's their mandate, not the mandate of timezone collectors to do the negotiation and diplomacy in order to arrive at and maintain the world standard.I certainly don't believe we have the mandate or skillset to ignore the  international standard widely used in modern computer technology.Sent from my Galaxy -------- Original message --------From: "Clive D.W. Feather via tz" <tz@iana.org> Date: 2021-09-22 03:34 (GMT-05:00) To: Tony Finch <dot@dotat.at> Cc: tz <tz@iana.org> Subject: Re: [tz] Preparing to fork tzdb Tony Finch said:>> Oh, please define "country".> Jon Postel deftly answered that question in the 1980s by deferring to ISO> 3166,Except that the ISO 3166 list contained Belorussia and Ukraine, both ofwhich were part of the USSR that was also in the list.The only reason they were in the list was a 1940s deal to give the USSRthree votes in the UN to counter the fact that there were more "western"countries than Warsaw Pact ones.So there was no genuine logic to that list, just politics.-- Clive D.W. Feather          | If you lie to the compiler,Email: clive@davros.org     | it will get its revenge.Web: http://www.davros.org  |   - Henry SpencerMobile: +44 7973 377646

On 2021-09-22 9:17 AM, Eliot Lear via tz wrote:

On 22.09.21 15:09, dpatte via tz wrote:

...

Iso is a living international standard, and it's their mandate, not the mandate of timezone collectors to do the negotiation and diplomacy in order to arrive at and maintain the world standard.

Right. And this group has avoided their business for decades.

I agree. There should be only one 'authority' for country codes, and ISO 3166 is it as far as I know. It seems it is the mapping of the country codes to time zone names (tags) that is causing the current difficulties. It seems to me it should not be such a problem. As zone1970.tab (and zone.tab) says: # This table is intended as an aid for users, to help them select timezones # appropriate for their practical needs. It is not intended to take or # endorse any position on legal or territorial claims. It is useful for "practical needs" but cannot be relied upon in all circumstances. Tzdb can use ISO 3166 but should not alter it or fall victim to any political controversies it might imply. I would point out, however, that zone1970.tab also contains the time zone *coordinates*. This is different matter than country codes. In the work I'm doing the coordinates are important. They define the approximate default coordinates of time zones, and this is useful in a number of ways, indicating geographic distances between time zones and distinction of Northern and Southern hemispheres. I think this has significance to the 'merging' controversy. "Europe/Oslo" is not the same time zone as "Europe/Berlin". They may have been using the same rule sets since 1970 resulting in identical local YMDhms representations but they have different time zone names (tags) and distinct coordinates. Oslo is not the same city as Berlin. If time zone "Europe/Oslo" ever existed it still exists today. "Europe/Oslo" could adopt a new set of rules different from "Europe/Berlin" and its possible they might given the new elective rules being suggested by the EU. Olsen's original insight to use towns and cities to name time zones turns out to be extraordinarily useful. Whether or not "Europe/Oslo" is in Norway is entirely beside the point of local time in the "Europe/Oslo" time zone. Time zones really exist only in the time domain relative to the (special) "Etc/UTC" time zone. I'm sure most contributors to the tz list understand this, but there's a natural tendency equate a time zone with a location or place since this is where the general idea comes from to begin with. But I think tzdb must be vigilant to maintain this conceptual separation of time zone v.s. "place", especially in regard to politically named and claimed geographic boundaries such as Norway or Germany. This separation of "time" from "place" may seem inconsistent with my previous point about time zone coordinates but I don't think so. The time zone names are based on cities and the cities have approximate geographical location and this ties the time zone to a location. This is useful for some important purposes and supports the basic idea behind time zones. But it is a separate conceptual and implementation consideration from the local time zone YMDhms representation with respect to "Etc/UTC". The geographic coordinates have nothing to do with the local time because any time zone may adopt any UTC-offset (STDOFF) or DST rules they choose and this decouples the time zone's local time from the city location. I'm sure most tzdb experts recognize this distinction but it seems to have somehow been lost track of recently. I hope participants can find the way back to the cooperation that has characterized the group for so long. Thanks, -Brooks Harris

On 2021-09-22 4:41 PM, Guy Harris wrote:

On Sep 22, 2021, at 11:32 AM, Brooks Harris via tz <tz@iana.org> wrote:

...

I would point out, however, that zone1970.tab also contains the time zone *coordinates*. A "time zone" isn't a point, it's a set of points - and, at least if "time zone" means "tzdb region", it's a set of points not guaranteed to be simply connected, so it doesn't have a single curve that represents its border.

As such, a "time zone" doesn't have a single coordinate pair, it has a whole bunch of coordinate pairs corresponding to its borders.

All that zone.tab and zone1970.tab have is:

# 2. Latitude and longitude of the timezone's principal location # in ISO 6709 sign-degrees-minutes-seconds format, # either ±DDMM±DDDMM or ±DDMMSS±DDDMMSS, # first latitude (+ is north), then longitude (+ is east).

The "principal location" is, presumably, the city or other location that gives the region its name; I live about 480 km from the "principal location" of the tzdb region I'm in. Yes, all true. I think that "principal location" is helpful as a default. But it is not accurate, and it does not define the "region". It's merely an approximate guide.

...

This is different matter than country codes. In the work I'm doing the coordinates are important. They define the approximate default coordinates of time zones, and this is useful in a number of ways, indicating geographic distances between time zones and distinction of Northern and Southern hemispheres. But it's not useful for determining in which tzdb region an arbitrary coordinate pair belongs, which is also important to at least some Darwin-based OSes (macOS, iOS, iPadOS, watchOS - I can't speak for tvOS), as that's how their mechanism for automatically determining your machine's current tzdb region works.

For that information, see

https://github.com/evansiroky/timezone-boundary-builder

which uses OpenStreetMap.

Yes, true. I don't believe providing information for automatic time zone detection is tzdb's responsibility. Its an application feature downstream from tzdb. But I think that "principal location" is a helpful starting point in some circumstances. Part of my observation is that the zone1970.tab contains *both* country code and coordinates, which couples the tz time zones to the country creating some part of the difficulty of avoiding politics as much as possible. Maybe ideally there should have been a 'coordinates' file and a 'country' file. I'm not suggesting this should change, only pointing out this is where tzdb got connected to country politics.

...

I think this has significance to the 'merging' controversy. "Europe/Oslo" is not the same time zone as "Europe/Berlin". They may have been using the same rule sets since 1970 resulting in identical local YMDhms representations but they have different time zone names (tags) and distinct coordinates. Oslo is not the same city as Berlin. San Francisco is not the same city as Los Angeles, but they're in the same tzdb region, so "city A is not the same city as city B" is insufficient region to have both Region/A and Region/B in the tzdb.

Europe/Oslo and Europe/Berlin are, in 2021a and earlier releases, separate tzdb regions for historical reasons, both in the sense of "they had different rule sets prior to 1970" and in the sense of "the process of setting up tzdb regions happened to give them separate regions".

Right. I feel retaining them in the main files is the best approach.

What Paul has noted is that there are cases where a single tzdb region covers locations not all of which have the same rules/offsets prior to 1970, and asks what's special about Norway and Germany.

Two ways of changing that are 1) merging tzdb regions so that Europe/Oslo is a link to Europe/Berlin when using the default data and a separate tzdb region when using the backzone data and 2) splitting other zones so that pre-1970 data is available for them as well.

Paul is going with 1) - and he notes that the backzone is still available and can be used.

Right. I think I'd have chosen to retain all time zones in the main well known source files and providing new files that support filtering and/or new features if that's the intention. But Paul has been more often right than wrong, so I guess we'll see.

...

If time zone "Europe/Oslo" ever existed it still exists today. "Europe/Oslo" could adopt a new set of rules different from "Europe/Berlin" and its possible they might given the new elective rules being suggested by the EU. If tzdb region "Europe/Oslo" had never existed, Norway could adopt a new set of rules different from those in "Europe/Berlin", and a new "Europe/Oslo" region created.

I.e., the *current* existence of a "Europe/Oslo" region is not at all necessary to allow a region that includes Oslo to adopt a new and different offset-from-UTC or new and different DST rules.

...

Olsen's original insight to use towns and cities to name time zones turns out to be extraordinarily useful. Whether or not "Europe/Oslo" is in Norway is entirely beside the point of local time in the "Europe/Oslo" time zone. Time zones really exist only in the time domain relative to the (special) "Etc/UTC" time zone. I'm sure most contributors to the tz list understand this, but there's a natural tendency equate a time zone with a location or place since this is where the general idea comes from to begin with. But I think tzdb must be vigilant to maintain this conceptual separation of time zone v.s. "place", especially in regard to politically named and claimed geographic boundaries such as Norway or Germany. Although, when it comes to determining whether to use Europe/Berlin or Europe/Oslo on your laptop/tablet/phone/watch, the geographic boundaries of Europe/Berlin, Europe/Oslo, etc. *do* matter.

Yes, that's part of my concern about merging Europe/Oslo with Europe/Berlin.

And there's no guarantee that tzdb region boundaries correspond exactly to national boundaries. (I live in one of the many countries that contain more than one tzdb region - and some of them differ for reasons other than how far they are from the IERS Reference Meridian, e.g. they differ base don whether they observe DST or not.)

Determining national boundaries and time zone regions is a difficult problem, probably impossible in cases like disputed boarders. We all understand tzdb cannot be perfect in all respects. It is, nonetheless, the best available collection of time zone information, having established itself as essentially the de facto standard defining civil time. We really don't want to see it broken.

On 2021-09-22 6:18 PM, Guy Harris wrote:

On Sep 22, 2021, at 2:49 PM, Brooks Harris <brooks@edlmax.com> wrote:

...

On 2021-09-22 4:41 PM, Guy Harris wrote:

...

On Sep 22, 2021, at 11:32 AM, Brooks Harris via tz <tz@iana.org> wrote:

The "principal location" is, presumably, the city or other location that gives the region its name; I live about 480 km from the "principal location" of the tzdb region I'm in. Yes, all true. I think that "principal location" is helpful as a default. How so? I'm over 400 km from my tzdb region's "principal location".

And what's special about 111 E 1st Street, Los Angeles, that makes it more "principal" than, for example, 2800 E Observatory Road, Los Angeles? It makes its "principal location" different than another time zone, such as "America/New_York".

...

Yes, true. I don't believe providing information for automatic time zone detection is tzdb's responsibility. Its an application feature downstream from tzdb. But I think that "principal location" is a helpful starting point in some circumstances. In what circumstances are those? Say we have an interchange format that includes:

a) tz time zone tag b) local tz date and time c) coordinate field The idea here is that some devices will be able to support accurate coordinates from GPS, like a truck, car, or smart phone. But many devices will not have GPS or other means of determining location. So, the tzdb supplied "principal location" coordinates are a much better default than zero-zero or "unknown".

...

Part of my observation is that the zone1970.tab contains *both* country code and coordinates, which couples the tz time zones to the country creating some part of the difficulty of avoiding politics as much as possible. Maybe ideally there should have been a 'coordinates' file and a 'country' file. I'm not suggesting this should change, only pointing out this is where tzdb got connected to country politics. One question is "should zone.tab and zone1970.tab officially even be considered part of the tzdb, or are they just "interesting additional data"?

I agree that's worth considering. One approach that could dispose of some of the controversy in one stroke would be to simply delete those files. But, once something is plugged in you can't turn it off. I expect such a suggestion would be met with some derision.

...

...

Although, when it comes to determining whether to use Europe/Berlin or Europe/Oslo on your laptop/tablet/phone/watch, the geographic boundaries of Europe/Berlin, Europe/Oslo, etc. *do* matter. Yes, that's part of my concern about merging Europe/Oslo with Europe/Berlin. Right now, the only difference that would make to the mobile machine in question is in applications that handle pre-1970 time stamps in the tzdb region in which they're currently located.

An application may be calculating times in some other or several other time zones. Its not just where its located.

For *those* applications, they would require a set of tzdb files that include backzone if they are to handle pre-1970 time stamps while the user is in, for example, Asmara. If they include backzone, they will be unaffected by the merger.

Those applications might also require some *additional* pre-1970 region splits in the future.

Yes, there will be ongoing changes no doubt. Tzdb is not easy.

Date: Wed, 22 Sep 2021 14:32:01 -0400 From: Brooks Harris via tz <tz@iana.org> Message-ID: <614B76A1.6030000@edlmax.com> | It seems it is the mapping of the country codes to time zone names | (tags) that is causing the current difficulties. No, it's not - the current issues have nothing whatever to do with zone names or country codes (which are two unrelated issues, the latter of which has only peripheral relevance to tzdb in any case). The current issue relates to what data is present in some of the zones as generated by default. That's it in its entirety. kre

Brooks Harris via tz said:

I agree. There should be only one 'authority' for country codes, and ISO 3166 is it as far as I know.

It seems it is the mapping of the country codes to time zone names (tags) that is causing the current difficulties. It seems to me it should not be such a problem.

Right. So why is "NO -> Europe/Berlin" a problem when "DE -> Europe/Berlin" isn't? I don't follow this argument. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

Tom Lane said:

...

Right. So why is "NO -> Europe/Berlin" a problem when "DE -> Europe/Berlin" isn't? I don't follow this argument.

In a vacuum, that'd perhaps be fine (although bad memories of WWII might be a reason to say it isn't). But I think the real reason for concern is that the proposed change causes a default build of tzdb to contain strictly worse (less accurate) data for NO than what was there before.

I see that point, though it depends on how you view pre-1970 data. After all, the data is already wrong for much of the area covered by Europe/Berlin and possibly (I wouldn't be surprised either way) much of the area covered by Europe/Oslo. But it's a completely different argument to the "but they're different countries" one that's been going around this list. That's the one that I don't understand. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

On 9/24/21 11:53 AM, Robert Elz via tz wrote:

there's nothing stopping us treating this as a somewhat special case (which it clearly is)

It's not that special (unless by "special" you mean "temporarily commanded by a Red Army general" :-). If you're concerned about pre-1970 timestamps Europe/Paris is wrong for most of France, America/New_York is wrong for most of the US Eastern time zone, etc., etc. I doubt whether it'd be possible even in theory to hash that all out, if one wanted accurate timestamps back to the introduction of standard time. Too many of the old records have been lost. But even if it were possible, it'd be a lot of work and nobody has the time and inclination to do it. We need guidelines that we can realistically follow and that result in an equitable database.

Robert Elz said:

| I see that point, though it depends on how you view pre-1970 data. After | all, the data is already wrong for much of the area covered by | Europe/Berlin and possibly (I wouldn't be surprised either way) much of | the area covered by Europe/Oslo.

It isn't "because they're different countries" but because there was data that is now (effectively) deleted

So, at the risk of putting words into your mouth that weren't there, you want to bring everything from backzone into the main distribution and have a policy of not getting rid of any zone that already exists? That's an arguable position (I don't know at this point if I agree with it) that's worth talking about.

In other words, any authority with the ability to make timezone changes who wants to have their own zone, with their own data (including as much of their own historical data as they can manage to collect) simply needs to change their timezone in some small way, and we have no choice but to give them a zone, after which they can submit the historical (pre 1970) data, and it will be included.

That's always been the case. I've not seen any authority bothering to do that, though - given that they don't bother to tell us about changes until a few days before, we clearly aren't high up on their list of important things to worry about. So I don't think this is a significant risk.

To the extent that we're concerned that even though Berlin is the correct choice for Germany according to the rules, its time history is not accurate for much of the rest of Germany, then there's nothing stopping us treating this as a somewhat special case (which it clearly is),

From another email, it's not just Berlin that's a special case. Just about every zone in the USA is a similar special case because, to paraphrase, until the mid-1960s practically every village had its own date for DST changes.

That the data doesn't differ post 1970 does not exclude a new zone, it just does not require that one be created, there's a discretion.

I can accept that. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

On Sep 24, 2021, at 8:05 AM, Clive D.W. Feather via tz <tz@iana.org> wrote:

I see that point, though it depends on how you view pre-1970 data. After all, the data is already wrong for much of the area covered by Europe/Berlin and possibly (I wouldn't be surprised either way) much of the area covered by Europe/Oslo.

The further back you go from 1970, the more likely that the data for the tzdb region you're in - even if all of backzone is included - is likely to be wrong for your current location. Fixing that would probably require a lot of detailed research, at least for some locations and, even if you don't try to give LMT for every location on earth, could involve creating significantly more tzdb regions. And the further you go back, the more research and the more tzdb regions will be necessary. So if the tzdb were to make an effort to improve the correctness of pre-1970 data over and above undoing all the moves to backzone, the cost - in effort required to get better data for existing regions, effort required to get data for any newly-created regions, effort required to maintain those new regions, *and* effort by at least some consumers of the to use the newly-created regions. It may be that the best pre-1970 data you'll ever get from the tzdb will be data for existing regions, including backzone regions, with whatever fixes are supplied by those interested in improving that data. You may never get, for example, finer-grained data for Germany than you have now, if there is any. So, yes, moving regions to backzone may just be replacing incorrect data with incorrect data, although the data moved to backzone might be "less wrong", if that matters to consumers of pre-1970 data. (BTW, macOS uses at least two relegated-to-backzone tzids - if I set my current city to Montreal, it sets the current tzdb region to America/Montreal, not America/Toronto, and if I set my current city to Asmara, it sets the current tzdb region to Africa/Asmara, not Africa/Nairobi. However, they don't appear to use the backzone data, as the America/Montreal and America/Toronto files are byte-for-byte identical, as are the Africa/Asmara and Africa/Nairobi files. I don't know whether, if I were to travel to Montreal or Asmara, they'd set the tzdb region to America/Montreal or Africa/Asmara, respectively. That depends on the map data they use, and whether it has those regions.)

On Sep 26, 2021, at 5:44 PM, Paul Eggert via tz <tz@iana.org> wrote:

On 9/22/21 11:32 AM, Brooks Harris via tz wrote:

...

Olsen's original insight to use towns and cities to name time zones turns out to be extraordinarily useful.

As a historical note, the naming convention you're talking about is something I originated and contributed to tzdb in 1993.

Yes - for example, back in 1992, the "Europe" file had these zones: $ git show a544b29c474e03e527df186cd9c33049bce31670:europe | egrep '^Zone' Zone GB-Eire 0:00 GB-Eire %s 1968 Oct 27 1:00s Zone WET 0:00 W-Eur WET%s Zone Iceland 0:00 - WET Zone Portugal 0:00 W-Eur WET%s 1992 Sep 27 1:00s Zone MET 1:00 M-Eur MET%s Zone Poland 1:00 W-Eur MET%s Zone EET 2:00 E-Eur EET%s Zone Turkey 3:00 Turkey EET%s Zone W-SU 3:00 M-Eur ???? (Paul, I think, constructed the tz Git repository, in part, from the original SCCS history from when SCCS was being used by Arthur).

International standard doesn't mean world standard. International standard only represent consencus reached by governments around the world, and in TZDB it is not only the governments decided time that are being recorded, but instead it record the time actually used by people for timekeeping on the ground. 在 2021年9月22日週三 21:09，dpatte via tz <tz@iana.org> 寫道：

Iso is a living international standard, and it's their mandate, not the mandate of timezone collectors to do the negotiation and diplomacy in order to arrive at and maintain the world standard.

I certainly don't believe we have the mandate or skillset to ignore the international standard widely used in modern computer technology.

Sent from my Galaxy

-------- Original message -------- From: "Clive D.W. Feather via tz" <tz@iana.org> Date: 2021-09-22 03:34 (GMT-05:00) To: Tony Finch <dot@dotat.at> Cc: tz <tz@iana.org> Subject: Re: [tz] Preparing to fork tzdb

Tony Finch said:

...

...

Oh, please define "country". Jon Postel deftly answered that question in the 1980s by deferring to ISO 3166,

Except that the ISO 3166 list contained Belorussia and Ukraine, both of which were part of the USSR that was also in the list.

The only reason they were in the list was a 1940s deal to give the USSR three votes in the UN to counter the fact that there were more "western" countries than Warsaw Pact ones.

So there was no genuine logic to that list, just politics.

-- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

On Tue, 21 Sept 2021 at 20:44, Paul Eggert via tz <tz@iana.org> wrote:

On 9/21/21 12:33 PM, Stephen Colebourne via tz wrote:

...

The current unreleased state of tzdb is that it favours some countries over others, such as Germany over Sweden/Norway.

It also "favors" some states over others, such as Arizona (which has the America/Phoenix Zone) over Utah (which has no Zone). It's the same argument, and it's an equally invalid argument as far as timekeeping goes.

No, this is patent nonsense. A US state is not of the same importance as a country. Stephen

Stephen Colebourne via tz said:

...

It also "favors" some states over others, such as Arizona (which has the America/Phoenix Zone) over Utah (which has no Zone). It's the same argument, and it's an equally invalid argument as far as timekeeping goes. No, this is patent nonsense. A US state is not of the same importance as a country.

Have you tried saying that in Texas? Certainly it's the impression we get over here. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

Paul Eggert via tz <tz@iana.org> writes:

This disagreement is not about whether the data in question are available; it's only about which file they're in. Nothing is being "wiped out" or refused.

The flaw in that assertion is that while the data may be there, it's no longer possible to extract it in a way that matches prior results. Consumers who value data stability are out in the cold. I just re-ran my experiment comparing the zoneinfo tree generated by 2021a to what I get from current tzdb git. I get the same set of zone files, except for a couple of expected recent changes such as Pacific/Kanton. However: * without backzone, there are 65 zone files/links that change contents compared to 2021a * with backzone, there are 95 zone files/links that change content. It looks like 25 of the changes are shared between the two trees and so probably represent actual recent updates, rather than effects of the May rearrangements. But that still leaves me with a need to change the contents of either 40 or 70 zone files for which there is absolutely no justification other than administrative fiat. I'm damned if I do and damned if I don't, and the only thing that's certain is that I'll have unhappy users. The same conundrum is going to face every tzdb repackager who is unwilling to assume that nobody cares about pre-1970 dates. I think there is going to be a fork, and I think a lot of people are going to adopt it rather than choose which subset of their users to annoy. Of those who don't follow the fork, some large fraction are going to start using backzone, reasoning that adding poorly-attested data for some zones is better than removing somewhat-better-attested data for other zones. That's going to leave us with three competing versions of tzdb, which is absolute disaster. But if you're going to assign negligible weight to data stability, that's what's going to happen, because a lot of us *do* value that. regards, tom lane

What equity, diversity or inclusion issues were in 2021a? How does the patch solve them or make the situation better? Is there a roadmap? There were multiple requests about Kiev -> Kyiv rename. And the patch can be interpreted as prioritising some time zones over the others. Won't it cause even more requests of that kind? Sorry if it was already answered, I couldn't find answers to these questions in archives. Thanks, Almaz On Mon, 20 Sept 2021 at 17:16, Paul Eggert via tz <tz@iana.org> wrote:

On 9/20/21 1:06 AM, Stephen Colebourne via tz wrote:

...

The purpose of the fork would initially be to maintain the tzdb data set as it was prior to the dispute.

Such a fork would arbitrarily discriminate against countries like Angola and Niger, and in favor of countries like Norway and Sweden.

A primary goal of the recent patches was to avoid racial or national preferences that were present in the previous setup. Arguably these preferences were not intentional, or were apparent and not real; however, that's not an argument I would want to defend.

Although the problem of discrimination could also be fixed in the fork you suggest, any such fix would take considerable work. It couldn't be done merely by reverting a patch or two. All this work would be need to be done before any such fork could be used by an organization that is committed to equity, diversity and inclusion.

Instead of forking, I suggest that we work together to address the technical issues raised by the change. I've been attempting to do that with the recent "Revert May patch to zone.tab" patch, which Almaz today said fixes the problems Google had with region-timezone mapping. I hope that we can address remaining technical problems with similar patches.

If the "Revert May patch to zone.tab" patch is not enough, one possible path forward would be to add a build-time option along the lines that I suggested to Tom Lane in <https://mm.icann.org/pipermail/tz/2021-June/030197.html>. This would let projects like PostgreSQL generate a tzdata.zi file containing whatever backzone entries they choose, though I would urge these projects to consider equity, diversity and inclusion issues when they make their choices. I have drafted a patch along these lines and could circulate it if there's interest.

The idea is to commit to an approach that accommodates users who need at least one tzdb entry per country, either via the "Revert May patch to zone.tab" or by further patches if necessary.

...

These have the effect of wiping out historic time-zone information on many locations where the data has been in tzdb for many years.

None of the information has been "wiped out". It has merely moved from one source file to another, and builds with PACKRATDATA=backzone still install all the info in question. This disagreement is not about "wiping out" info; it's about what category the info falls into.

Date: Thu, 23 Sep 2021 01:52:28 -0700 From: Paul Eggert via tz <tz@iana.org> Message-ID: <cd323514-14cd-245f-0979-2edf91f5b59e@cs.ucla.edu> | Locations in countries like Norway and Sweden got special treatment by | being Zones, whereas locations in countries like Angola and Ethiopia | were only Links. Then make the latter zones instead of links. | It replaces Zones with Links when Links suffice. That way, Norway etc. | are treated like Angola etc. Which could be fixed better the other direction. | The job is done now. There's no reason to make further changes like this. Except that every time one of the zones which is now a link decides to change its timezone rules, it needs to be converted back to a zone. That wouldn't be required if they were left zones in the first place. | Only in the sense that the currently-prioritized timezones are those | that differ since 1970, which is a timekeeping issue that the tzdb | guidelines say is our priority. Priority, yes, but that doesn't mean that nothing before then is relevant. | This is in contrast to 2021a, where some | timezones were prioritized for reasons unrelated to timekeeping. If we stepped back to 2001 or so, and made sure that all the zones which were zones then, continued to be zones now, then we would have none of these problems. All this has been inspired by this unnecessary desire to have less zones, which is something I have never understood. One zone (at least) per authority (nb: not country) should be the goal, as I recall it, that's what we used to have. And to answer Clive's question about whether Wales should have its own timezone, the answer entirely depends upon whether the Welsh parliament (such as it is) has the authority to alter the time in Wales, if it does, then yes, there should be a Europe/Cardiff (my guess as to the largest population centre in Wales, not intended to necessarily be correct). If it does not, then no, not unless the British parliament (or whoever it delegates to make this decision) decides to make the time in Wales differ from the rest of the UK. | but because of Samoa we really need to get a new release out | soon and so will have to make do with what we have, somehow. Yes, 2021a, plus those changes (and anything else similar). No more zone merging. kre

The Department of Transportation sets the boundaries of the time zones, but states (and tribes) can opt out of daylight savings time. Envoyé de mon iPhone

Le 23 sept. 2021 à 08:20, Clive D.W. Feather via tz <tz@iana.org> a écrit :

Robert Elz via tz said:

...

One zone (at least) per authority (nb: not country) should be the goal, as I recall it, that's what we used to have.

Do we know who the authorities are?

Three examples:

(1) I don't know who the authorities in the USA are. I know that the Secretary of Transport has some kind of authority, but I was under the impression that state governments are also involved in changing what zone a state is in. I know that Arizona seems to have at least three separate authorities. And as for the mess in Indiana ...

(2) The EU is the authority for the transition rules throughout the EU, but doesn't select what zone a country is in. That's a national matter.

(3) Does Eucla have an authority? Or was it just a few people in the pub that decided to change the clocks and everyone else went along with it?

(Does Eucla have a pub? Surely it does - it's in Oz.)

...

And to answer Clive's question about whether Wales should have its own timezone, the answer entirely depends upon whether the Welsh parliament (such as it is) has the authority to alter the time in Wales,

So far it doesn't.

And you've missed my point, which is that people (e.g. the Welsh) don't accept 3166 as the authoritative list of countries for domain names, so why would they for time zones. Which is why "at least one zone per 3166 'country'" isn't automatically going to prevent political arguments.

-- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

Date: Thu, 23 Sep 2021 13:19:15 +0100 From: "Clive D.W. Feather" <clive@davros.org> Message-ID: <YUxwwy90bZHzrtrU@davros.org> | Do we know who the authorities are? No, but we don't need to in advance - when someone demonstrates that some authority is changing the time in some region, that shows the existence of such an authority. | (1) I don't know who the authorities in the USA are. Nor do I, but someone does. Probably many someones. My believe from what I have seen (mostly here) though is that the states don't get to make decisions themselves, but can make requests. | (2) The EU is the authority for the transition rules throughout the EU, but | doesn't select what zone a country is in. That's a national matter. Yes, that's what I understood too, and so each country should have at least one zone. It doesn't matter if (for example) San Marino has never had times different from Rome (even if that goes back hundreds of years). (I also have no idea if San Marino is an EU member, I'm just guessing.) | (3) Does Eucla have an authority? Or was it just a few people in the pub | that decided to change the clocks and everyone else went along with it? That is the authority. No-one ever said it needs a legislative basis, just that it decides what the clocks should be set to, and that actually takes effect. How (or where) they decided to split the difference between SA and WA times I have no idea (though it does make sense). | (Does Eucla have a pub? Surely it does - it's in Oz.) I would assume so, but I have never been there. I know it isn't very big though. | And you've missed my point, which is that people (e.g. the Welsh) don't | accept 3166 as the authoritative list of countries for domain names, No, I didn't miss that, I understood what you were saying, my point was that, IMO anyway, the answer to that is irrelevant to time zones. What is and what is not a country is irrelevant - which is why the exact status of Palestine doesn't matter to us, it has its own time zone, with its own rules, and someone is deciding what they should be. That is enough. Similarly, in AU, it is the states that decide on timezones, summer time rules, etc, not the commonwealth govt - each state is an authority. And to answer a point that Paul made in response to a much earlier message of mine (a few days ago, so hundreds of messages back...) the authorities that matter are those that exist now (and into the future) - that is, those who can decide, now, to alter what the time is. What various towns might have done a couple of hundred years ago is only relevant if they're still doing that today. So Eucla counts, Sacramento doesn't. kre

Stephen Colebourne via tz said:

Taken at face value, it is easy for anyone reading this to nod their head and agree that Norway should not receive favouritism over Angola.

What it fails to state is that the solution adopted (creating Links where previously there were Zones) has created a *different* equity, diversity or inclusion issue. The resulting tzdb state clearly favours Berlin over Oslo or Stockholm, Brussels over Amsterdam.

The justification for this new inequality is arcane to anyone who doesn't understand the nuances of the tzdb system. Sure there is a rule involved (single regions for post 1970 data, largest city for pre-1970 data). But the rule simply won't be understood or accepted by most actual users of the data set.

But TZDB already favours London over Bristol, Paris over Lyons, Amsterdam over Den Haag, Berlin over Frankfurt, Los Angeles over Seattle, and so on. Without using the word "country", please explain the difference. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

On 9/23/21 7:37 AM, Tom Lane via tz wrote:

Timekeeping laws are generally set at the country level.

I wouldn't put it that way. The EU sets timekeeping rules that are binding across member states. Although members have some flexibility, so far it's been very unlikely, for example, that Sweden would diverge from Germany. (This may of course change in the future, in which case we'll of course deal with it.) Conversely, although the US federal government sets overall rules, it devolves DST decisions to states. If the rule were "at least one Zone per political unit that has the legal power to set its own rules", we'd have dozens more Zones than we do now, Zones that would cause more trouble than they'd cure. Although most countries do set timekeeping laws at the country level, counterexamples are so numerous and significant that it's too much to say that they're generally set that way.

Date: Thu, 23 Sep 2021 14:14:33 +0100 From: "Clive D.W. Feather via tz" <tz@iana.org> Message-ID: <YUx9uVqhCngF4JXv@davros.org> | But TZDB already favours London over Bristol, Bristol doesn't get to decide what time it sets the clocks to, so unless they start doing that (they could, though the British govt probably would not like it) or it is done for them, they're subservient to the UK time authority, and that one we call Europe/London (and would do so even if the ministry that recommends these things happened to have its offices in Birmingham). The Netherlands, Norway, Sweden, etc, all have the authority to choose their own time zone, unless the EU parliament decided to remove that choice from them (and they accepted that), so they ought be separate zones (the names those take are established by the tzdb rules, which aren't of relevance right now). kre

Speaking of Angola: Africa/Luanda was moved to backward in [1]. The commit message says that it's due to "now-abandoned guideline that every ISO 3166 code should have a zone". Ethiopia: Africa/Addis_Ababa was moved to backward in [2]. NEWS file in it tells "Some more zones have been turned into links, when they differed from existing zones only for older time stamps". Using repo history only I get the impression that in 2021 you merge zones because they were merged in 2014. I don't understand how that process is related to (or improves) equity, diversity or inclusion issues. What do I miss here?

It replaces Zones with Links when Links suffice. That way, Norway etc. are treated like Angola etc.

The reasons mentioned in commit messages do not apply to Norway.

The job is done now.

Sorry, I was unclear. What I meant was what is overall goal of this refactoring. I guess steps are not that important now.

The recent patches are orthogonal to the Kiev -> Kyiv rename

Yes, they are. But I think it still might raise concern from users. tl;dr: Sorry, I've started to follow tz mailing list only recently, I don't know all the historic decisions. But looking to commit messages history only, I get a weird impression around recent changes. [1] https://github.com/eggert/tz/commit/2a18a625a0171e5c54249a54179eda3409b1b838... [2] https://github.com/eggert/tz/commit/6f6f20f0bc739ce3dfd503700b793c5e459e309d On Thu, 23 Sept 2021 at 09:52, Paul Eggert <eggert@cs.ucla.edu> wrote:

On 9/22/21 2:53 AM, Almaz Mingaleev wrote:

...

What equity, diversity or inclusion issues were in 2021a?

Locations in countries like Norway and Sweden got special treatment by being Zones, whereas locations in countries like Angola and Ethiopia were only Links.

...

How does the patch solve them or make the situation better?

It replaces Zones with Links when Links suffice. That way, Norway etc. are treated like Angola etc.

...

Is there a roadmap?

The recent patches implement the last part of a long-term process that replaced Zones with Links when Links suffice. The process started in 2013. I worked gradually; I lacked time to do it all at once.

The job is done now. There's no reason to make further changes like this.

...

There were multiple requests about Kiev -> Kyiv rename. The recent patches are orthogonal to the Kiev -> Kyiv rename, because that city has a unique timezone history since 1970 and so gets a Zone under the guidelines, independently of how the Zone is spelled.

...

Won't it cause even more requests of that kind?

I doubt whether the change will affect the number of name-change requests. The patches did not affect names; they merely changed some Zones to Links.

...

And the patch can be interpreted as prioritising some time zones over the others.

Only in the sense that the currently-prioritized timezones are those that differ since 1970, which is a timekeeping issue that the tzdb guidelines say is our priority. This is in contrast to 2021a, where some timezones were prioritized for reasons unrelated to timekeeping.

...

Sorry if it was already answered, I couldn't find answers to these questions in archives.

This stuff is scattered all over the place, unfortunately. It would be helpful if I (or someone else) had the time to write it up. I hope this email is enough in the meantime.

PS. I apologize for not answering your email earlier, as well as not replying to everyone else's email. Unfortunately I'm swamped with email now, much of it not tzdb-related. It will take time to consider all the suggestions made recently, but because of Samoa we really need to get a new release out soon and so will have to make do with what we have, somehow.

On Sep 24, 2021, at 9:35 AM, Almaz Mingaleev via tz <tz@iana.org> wrote:

Speaking of Angola: Africa/Luanda was moved to backward in [1]. The commit message says that it's due to "now-abandoned guideline that every ISO 3166 code should have a zone". Ethiopia: Africa/Addis_Ababa was moved to backward in [2].

Presumably you meant "moved to backzone". "backward" "provides links between current names for timezones and their old names", and contains no data, just Link lines. backward does have Link Africa/Nairobi Africa/Asmera Africa/Asmera would be a link even if we brought all backzone entries back to the main database - it'd be a link to Africa/Asmara. I don't know whether Link works transitively, so I don't know whether Link Africa/Asmara Africa/Asmera would work, given that there's also Link Africa/Asmara Africa/Asmera in the africa file.

On Sep 20, 2021, at 12:15 PM, Paul Eggert via tz <tz@iana.org> wrote:

A primary goal of the recent patches was to avoid racial or national preferences that were present in the previous setup.

I applaud the motivation to make these changes. But is it really ethical to knowingly introduce incorrect information into the default configuration, where previously the information was correct? Even if said information is “historic” or even “not officially supported”? You have billions of consumers. If you ship it, people are using it, even if they represent comparatively small numbers. If I’m understanding things correctly, a non-zero amount of people previously consuming correct information will silently start consuming incorrect information after upgrading to a new tzdb version — and we’re doing that on purpose. Howard

On Sep 22, 2021, at 8:00 PM, Guy Harris <gharris@sonic.net> wrote:

On Sep 22, 2021, at 4:49 PM, Howard Hinnant via tz <tz@iana.org> wrote:

...

I applaud the motivation to make these changes. But is it really ethical to knowingly introduce incorrect information into the default configuration, where previously the information was correct? Even if said information is “historic” or even “not officially supported”?

As per my mail, is the issue here that the Europe/Oslo information, for example, is believed to be correct, whereas the America/Montreal data, apparently moved to backzone in 2015, is *not* believed to be correct?

I believe we’re discussing 2021b, not 2015x. If we made a mistake in 2015, we should fix it, not use it as a justification to make the same mistake again today. Howard

On Sep 22, 2021, at 8:18 PM, Guy Harris <gharris@sonic.net> wrote:

(I don't hold any of those views at all firmly. My personal preference for what to do in the short term is "put out 2021a plus fixes such as Samoa as 2021b, don't put out the results of the merger yet, and discuss this further to see which of those, if any, should be adopted as the new policy, or pick a policy that's not in the list if that's where we end up".)

Here we are firmly agreed. I sincerely hope that the TZ Coordinator will take this path. Howard

Howard Hinnant via tz said:

...

A primary goal of the recent patches was to avoid racial or national preferences that were present in the previous setup.

I applaud the motivation to make these changes. But is it really ethical to knowingly introduce incorrect information into the default configuration, where previously the information was correct? Even if said information is ???historic??? or even ???not officially supported????

My understanding of the default setup is: * If two places had different times at any point since 1970, they must have separate zones. * If two places had the same time at all points since 1970, they do not have to have the same zone even if they differed before 1970. * The data for a zone applies to the whole zone for times after 1970, but might only apply to part of the zone before 1970. That might not be the best arrangement but, if I'm understanding correctly, it's what we've got. Based on that, then an alien observer would say that the area currently covered by the nation-states of Germany, Norway, and Sweden is allowed to be a single zone. And, if we were creating the TZDB from new right now, then under those rules plus the desire to minimize the number of zones, they would be a single zone. The data in them is *not* incorrect; it meets the policy described above. Therefore any argument that they should be two or three zones instead needs to be based on some *other* objective requirement. Which, I suspect, needs to be *added* to the present policies rather than just handwaved. Such requirements could be: * Never abolish a zone once it's got into the default setup. * At least one zone per 3166 "country". * At least one zone per "authority". * Use separate zones if we have reliable data going back to 1945 (or pick some other year). -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646

Kevin Kenny via tz <tz@iana.org> writes:

I could live with this. My chief concerns are (a) we should not arbitrarily make data that are believed to be reliable more difficult to access; (b) we should not surprise users by suddenly making them see different names for their home time zones. (For a Norwegian suddenly to have 'Berlin' instead of 'Oslo' appear is not acceptable.) Could we establish the rule, "don't abolish zones once released, even if they are subsequently discovered to be duplicative"?

I think that rule already exists --- the problem is that instead of removing zone names altogether, we're willing to make them misleading by linking them to data for some nearby location (for possibly large values of "nearby"). It's that practice that needs to go, in one way or another. regards, tom lane

On Sep 20, 2021, at 7:23 PM, Watson Ladd <watson@cloudflare.com> wrote:

On Mon, Sep 20, 2021 at 9:51 AM Howard Hinnant via tz <tz@iana.org> wrote:

...

The C++20 standard has adopted the IANA timezone database (not the code) as the basis for a major part of its API: http://eel.is/c++draft/time.zone#general-1

I plea for stability. That doesn’t mean no changes. But it does mean no drastic changes.

Unfortunately you are held hostage to the wishes of British Canadian chicken farmers, Indiana counties, etc, etc. in determining what the zones will be.

Adding new zones is not problematic. Removing or changing the names of existing ones is.

The set of zones may increase due to post-1970 changes in ways that we cannot predict. And the C++20 standard thankfully does not include the list of zones in the API.

A C++20 programmer can easily obtain the list of time zone names and link names from the already standardized API: #include <chrono> #include <iostream> int main() { for (auto& tz : std::chrono::get_tzdb().zones) std::cout << tz.name() << '\n'; for (auto& link : std::chrono::get_tzdb().links) std::cout << link.name() << '\n'; } Current output: Africa/Abidjan Africa/Accra Africa/Algiers Africa/Bissau ... Howard

On Sep 20, 2021, at 10:57 PM, dpatte <dpatte@relativedata.com> wrote:

When I read an astronomical journal and read of a bolide sighting in 1957 at 7:30 PM in haiti, it is important that I can attach that to a ut in 1957. But if it's now in the 'merged data' I am now out of luck.

In C++-speak: #include <chrono> #include <iostream> int main() { using namespace std; using namespace std::chrono; zoned_time zt{"America/Port-au-Prince", local_days{1957y/June/5} + 19h + 30min}; cout << format("%F %T %Z", clock_cast<tai_clock>(zt.get_sys_time())) << '\n'; } Output: 1957-06-06 00:30:10 TAI Note that programmers are hard-coding the name "America/Port-au-Prince”. Howard

On Sep 21, 2021, at 1:49 AM, Steve Allen via tz <tz@iana.org> wrote:

On Mon 2021-09-20T23:34:25-0400 Howard Hinnant via tz hath writ:

...

zoned_time zt{"America/Port-au-Prince", local_days{1957y/June/5} + 19h + 30min}; cout << format("%F %T %Z", clock_cast<tai_clock>(zt.get_sys_time())) << '\n';

...

Output:

1957-06-06 00:30:10 TAI

anything that produces a value of TAI for a date in 1957 has created a fantasy world that does not correspond to reality.

After I hit send I thought I may have gone a step too far in converting to TAI. Leaving that conversion out simplifies things and does not negate my point: that IANA time zone names are part of the C++20 API, and pre-1970 data is expected (best effort of course): zoned_time zt{"America/Port-au-Prince", local_days{1957y/June/5} + 19h + 30min}; cout << format("%F %T %Z", zt.get_sys_time()) << '\n'; Output: 1957-06-06 00:30:00 UTC

On Sep 21, 2021, at 10:29 AM, Jan Engelhardt <jengelh@inai.de> wrote:

On Tuesday 2021-09-21 15:20, Howard Hinnant via tz wrote:

...

...

On Mon 2021-09-20T23:34:25-0400 Howard Hinnant via tz hath writ:

...

zoned_time zt{"America/Port-au-Prince", local_days{1957y/June/5} + 19h + 30min}; cout << format("%F %T %Z", clock_cast<tai_clock>(zt.get_sys_time())) << '\n';

[...] IANA time zone names are part of the C++20 API, and pre-1970 data is expected (best effort of course):

zoned_time zt{"America/Port-au-Prince", local_days{1957y/June/5} + 19h + 30min}; cout << format("%F %T %Z", zt.get_sys_time()) << '\n';

I can't really find substance to this claim.

The API [speaking of the locate_zone() function] wants a string, but it does not specify which particular string value(s) is/are needed to get any particular zone. locate_zone can succeed or it can fail.

This issue was discussed in committee, and is a most delicate one (to get the wording right). In the end we believed that this sentence was the best way to describe the set of time zone names: http://eel.is/c++draft/time.zone#general-1

[time.zone] describes an interface for accessing the IANA Time Zone Database that interoperates with sys_­time and local_­time. This interface provides time zone support to both the civil calendar types ([time.cal]) and to user-defined calendars.

We also added a link the Bibliography section, which is unfortunately not included in the online document:

* IANA Time Zone Database. Available from: https://www.iana.org/time-zones

I was there, and I authored and championed this proposal through the standardization process. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0355r7.html Visual Studio is already shipping it. Howard

On Sep 21, 2021, at 11:15 AM, Jan Engelhardt <jengelh@inai.de> wrote:

On Tuesday 2021-09-21 16:45, Howard Hinnant wrote:

...

...

...

...

...

zoned_time zt{"America/Port-au-Prince", local_days{1957y/June/5} + 19h + 30min}; cout << format("%F %T %Z", clock_cast<tai_clock>(zt.get_sys_time())) << '\n';

[...] IANA time zone names are part of the C++20 API, and pre-1970 data is expected (best effort of course)

I can't really find substance to this claim. The API [speaking of the locate_zone() function] wants a string, but it does not specify which particular string value(s)

In the end we believed that this sentence was the best way to describe the set of time zone names:

http://eel.is/c++draft/time.zone#general-1

...

[time.zone] describes an interface for accessing the IANA Time Zone Database [...]

With a standard wording so loose, the best interpretation I can give you is that the minimum set of known names in C++20 is that of tzdata1996l.

Here are detailed instructions for making suggestions to improve the wording of the C++ standard. Everyone is welcome to contribute: https://cplusplus.github.io/LWG/lwg-active.html#submit_issue

Which may be lacking America/Port-au-Prince. (Probably not, but humour me.)

The C++20 spec also has API to inspect the version of the time zone database. Howard

The current tzdb only have separate zone for data up to 1970, other than
some exceptions
Forking to include data from earlier times need to considering willingness
of general data user to switch over with a larger-sized database and less
stable[due to foreseeable upcoming contribution to historical timezone] as
well as less accurate data from the past, especially when the number of
computer applications and OS in modern time need to handle files with
timestamps before 1970 is probably relatively less.
It was not without precedent that data that were same after 1970 being
moved away from the main tz file in tz db, with examples including Chinese
timezones except Xinjiang, as well as Japanese Southwestern Islands
timezone.

在 2021年9月21日週二 13:43，Guy Harris via tz <tz@iana.org> 寫道：

> On Sep 20, 2021, at 7:57 PM, dpatte via tz <tz@iana.org> wrote:
>
> > When I read an astronomical journal and read of a bolide sighting in
> 1957 at 7:30 PM in haiti, it is important that I can attach that to a ut in
> 1957. But if it's now in the 'merged data' I am now out of luck.
>
> As long as it's well established that Haiti didn't observe DST in 1957, as
> the current northamerica file claims is the case, that works.
>
> If it's not, well....
>
> (I.e., how "reliable" data for a given tzdb region and a given time in the
> past is probably depends on how far back in the past it is and how well
> offset and time-shifting rule changes are documented - and what sources
> people have checked.)
>

On Sep 21, 2021, at 11:58 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:

On 9/20/21 9:51 AM, Howard Hinnant via tz wrote:

...

The C++20 standard has adopted the IANA timezone database (not the code) as the basis for a major part of its API: http://eel.is/c++draft/time.zone [Retitling since the C++20 time library is a different topic.]

Here are comments about that draft. Hope they help. Unfortunately I got only about halfway thru the draft before running out of time.

Thanks for taking the time for this constructive criticism.

* Although the draft distinguishes Zones from Links, such a distinction is not available on platforms that use a filesystem's hard links to implement Links. For example, on Solaris 10:

$ cd /usr/share/lib/zoneinfo $ ls -li Asia/Chongqing Asia/Chungking Asia/Harbin Asia/Shanghai PRC 303178 -rw-r--r-- 5 root bin 148 2018-09-24 11:26 Asia/Chongqing 303178 -rw-r--r-- 5 root bin 148 2018-09-24 11:26 Asia/Chungking 303178 -rw-r--r-- 5 root bin 148 2018-09-24 11:26 Asia/Harbin 303178 -rw-r--r-- 5 root bin 148 2018-09-24 11:26 Asia/Shanghai 303178 -rw-r--r-- 5 root bin 148 2018-09-24 11:26 PRC

with no indication that Asia/Shanghai is the Zone and the other names Links. If there's a reason that the draft distinguishes Zones from Links, I suggest explaining the reason, and saying what implementations should do when the distinction between Zones and Links is not available. Another possibility is to remove the distinction between Zones and Links.

Agreed that the link part of the database may be zero-sized on some platforms. The API minimizes the distinction between zones and links by having the lookup of all names search both the zones and the links. The interested programmer can still ferret out a distinction. But the casual programmer will see the union of zones and links as just one big set.

* Minor wording nit: in the "remote_version" description, change "The latest remote database version" to "The current remote database version". It's possible that the current remote version is a downgrade or sidegrade from the local database version; the API still works in this case.

Good point, thanks.

* Exception classes. I see a problem with leap seconds here. These classes and their related operations seem to be designed only for local timestamps that are ambiguous and/or missing due to UTC offset changes, such as switching from standard to daylight-saging time. However, timestamps can also be ambiguous and/or missing due to leap seconds, and this is true regardless of whether the timestamp is local time or UTC.

For example, if there is a negative leap second at the end of 2023, the timestamp 2023-12-31 23:59:59 UTC will be missing, and similarly for simultaneous localtime timestamps. Conversely, if there is a positive leap second at the end of 2025 and local time is not an integral number of minutes away from UTC, some (but not all) implementations have ambiguous localtime timestamps; see <https://mm.icann.org/pipermail/tz/2021-September/030377.html> for an example. Also, perhaps a local timestamp's UTC-offset ambiguity could interact with the same timestamp's leap-second ambiguity, though such cases should be rare.

This part of the library is specified to be interoperable with Unix Time (http://eel.is/c++draft/time.clock.system#overview-1). Thus leap seconds are excluded by design. There does exist a separate facility, utc_clock (http://eel.is/c++draft/time.clock.utc) that is specified to include leap second information. However to interoperate with the time zone facility, a conversion from utc_time to sys_time is necessary. This conversion specifies exactly how the leap second is dealt with in the event that the source time_point points within a leap second. The utc_clock/utc_time facility is mainly useful if you need the duration between two time_points that potentially includes one or more leap seconds. It is also useful for communicating with external API’s that include leap seconds in their data structures (e.g. https://github.com/HowardHinnant/date/wiki/Examples-and-Recipes#ccsds). Howard

On Sep 21, 2021, at 12:59 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:

On 9/21/21 9:29 AM, Howard Hinnant wrote:

...

Agreed that the link part of the database may be zero-sized on some platforms.

That's fine, but could a note or footnote be added to that effect? For example, the text should make it clear that even given the same tzdb version, the same entry could be a Zone on one platform and a Link on another.

I’ll see what I can do.

...

This part of the library is specified to be interoperable with Unix Time (http://eel.is/c++draft/time.clock.system#overview-1). Thus leap seconds are excluded by design.

Ah, OK. Unfortunately that's not obvious from the text, which has an extensive discussion of leap seconds.

I suggest adding some text that makes it clear that the leap second interfaces are only for interrogating tzdb, and that leap seconds are not used by the conversion functions. For example, it should be clear what conversion functions do when given a tzdb entry that has leap seconds - do they ignore the leap seconds, or report an error, or what?

The “right” form of the tzdb should not be used for C++. Howard

On Sep 21, 2021, at 1:19 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:

One other thing. Internet RFC 8536 discusses TZif file truncation, and says that TZif files should not be used to convert timestamps outside of the truncated range. This discussion is improved in the latest draft for RFC 8536's successor, here:

https://datatracker.ietf.org/doc/draft-murchison-rfc8536bis/

which also talks about expiration of leap second tables.

Should the C++20 time library address the issues of TZif truncation and leap second table expiration, or treat these issues as being out of scope? Either way, some text would be advisable.

The standard does not specify that the source form of the database is TZif, though this is likely on platforms which already deploy TZif. Leap second table expiration is a possible feature for a future standard. You are correct that it currently does not exist. Howard

Guy Harris wrote in <8C6BA6DA-AC7D-4FCE-97F0-1B277A981B55@sonic.net>: ... |So one difference here appears to be that the pre-1970 data for Europe/O\ |slo may be accurate while the pre-1970 data for America/Montreal may \ |be inaccurate. But isn't the drive to backzone going on for longer, yes hasn't it been introduced for exactly the purpose in 2014? ac5bf48519 New data file 'backzone' for out-of-scope and/or poorly-sourced data. where NEWS says A new file 'backzone' contains data which may appeal to connoisseurs of old time stamps, although it is out of scope for the tz database and is often poorly sourced. The new file is not recommended for ordinary use and its entries are not installed by default. (Thanks to Lester Caine for the Guernsey, Jersey, and Isle of Man entries in 'backzone'.) Ever since i am on this ML (at least a decade i would say) over and over again it is said to everybody that the IDs are just strings and the data is the thing, that selection is a downstream thing etc etc etc. I surely hated it, but that is seven years! |Another difference is that Toronto and Montreal are in the same country, \ |while Oslo and Berlin aren't. The thing is that _i_ never treated links as links, even my dumb brain did manage to get by to separate data from names. (I posted some code snippets many years ago. Yes, negative leaps i failed for. It was just a single binary DB file with the zone data and at the end a TOC of names pointing to offsets of their data. I was prowd by then, i was stupid. Whatever.) Ever since i am on this ML it was discussed often to possibly replace the identifiers with anonymized strings, i wonder how anyone could create an interface where one name maps to another name. And what for? This is not just "super correct" and "i give my users the full knowledge of the real thing, of anything", that is just broken. It is anyway a programmer-only thing, maybe also a UNIX command line power user thing -- but to get it _really_ right for _users_, you had to use ICU data and use their approach of time zones, that includes translation then also, does it? You know, as a human german speaking being i would _never_ assume Europe/Vienna and do "$ TZ=Europe/Vienna date" really, that is a nerd assumption. Maybe "$ date --country=AUstrIA" or "$ date --city Würzburg" or "$ date --state Baden-Württemberg", and i only write this for case-messing out-of-ASCII. Sorry for getting bold, but for one i really did not make that error (!), and then i also find it absurd to claim to offer a timezone interface that covers all the date and time data, and then to exclude backzone. That is schizophrenic, that is fascistic, because of course bad quality data that has been collected from an uncounted number of sources (and Mr. Eggert seems to be very interested in the topic, and actively sleuths in libraries and other sources to improve his knowledge on the topic, which i cannot claim from myself) is much better than simply excluding the few traces that exist, and asserting "this is the best i can offer". I do not think Joda would do that. (iirc) On the other hand the announced release strategy felt offending to me. Even though many hours of talking over several months were spent where possibly some code fixes etc would have been due. Also, for JAVA in particular, i seem to remember that there was discussion that it really would be better to use custom JAVA tarballs for downloading already years ago, but it seems nothing changed. If it would, then a simple sed(1) that postprocesses any Link would have been put in place, maybe. I also remember that in the last discussion it seemed at least one of my mails was forwarded behind the scenes before the administrator (whoever it is) waved it through. I really do not know what for. One approach could for example be to _require_ a new build flag, so that downstream consumers aka packagers which do not read the list but only have robots sitting around that watch out for releases will get build failures, and thus have to adjust their packaging recipe. Then the release announcement could also prominently reassert the IANA TZ direction of going post 1970 by default, but to not actively cut zone data at 1970, ie, that backzone is needed for the full picture if you want to get it right. This does not satisfy data-only downstream consumers, but then again these should really know what they are doing. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

Guy Harris wrote in <B97CABBF-BFEA-4CE5-9D05-9663170ABBE0@sonic.net>: |On Sep 23, 2021, at 5:41 AM, Steffen Nurpmeso <steffen@sdaoden.eu> wrote: |> Guy Harris wrote in |> <8C6BA6DA-AC7D-4FCE-97F0-1B277A981B55@sonic.net>: |> ... |>|So one difference here appears to be that the pre-1970 data for Europe/O\ |>|slo may be accurate while the pre-1970 data for America/Montreal may \ |>|be inaccurate. And the README even says This database of historical local time information has several goals: * Provide a compendium of data about the history of civil time that is useful even if not 100% accurate. |> But isn't the drive to backzone going on for longer, yes hasn't it |> been introduced for exactly the purpose in 2014? | |I.e., one to two years longer, given that America/Montreal was introduced \ |in 2015 (as I believe I noted when I first brought up America/Montreal \ |in this context). | |> Ever since i am on this ML it was discussed often to possibly |> replace the identifiers with anonymized strings, i wonder how |> anyone could create an interface where one name maps to another |> name. | |If I open up System Preferences on my machine, select the "Date and \ |Time" entry, select the "Time Zone" tab, enable editing via a couple \ |of steps, and type "Oxnard" into the "Closest City" box, under the \ |hood it maps "Oxnard, CA" to "America/Los_Angeles", setting the current \ |system tzdb region to the latter. (And then I go back to "figure it \ |out automatically based on where I'm currently located", but I digress....) | |Is that what you mean by "one name maps to another name"? There's \ |no "America/Oxnard", so it needs to figure out that Oxnard is in the \ |tzdb region that's named "America/Los_Angeles". This is malicous hairsplitting for nothing. If a programming interface gives you one TZ name for another TZ name where both effectively indistinguishable select the same data. The first name had to be selected first, why would you want it to be mapped? backward is not timing out, i think. |> And what for? This is not just "super correct" and "i give |> my users the full knowledge of the real thing, of anything", that |> is just broken. It is anyway a programmer-only thing, maybe also |> a UNIX command line power user thing -- but to get it _really_ |> right for _users_, you had to use ICU data and use their approach |> of time zones, that includes translation then also, does it? | |macOS *does* include ICU, but the string "Oxnard" appears nowhere in \ |CLDR as of cldr-28, so I suspect it uses more than just ICU data. | |> You know, as a human german speaking being i would _never_ assume |> Europe/Vienna and do "$ TZ=Europe/Vienna date" really, that is |> a nerd assumption. Maybe "$ date --country=AUstrIA" or |> "$ date --city Würzburg" or "$ date --state Baden-Württemberg", |> and i only write this for case-messing out-of-ASCII. | |Sounds good. That would require data of the sort that macOS uses; \ |could OpenStreetMaps data be used? Well _i_ do not think that sounds good, i think reality is you go to a mega companies app store, download one, and then input or even speak a name. |Anyway: Yes, please! |> Sorry for getting bold, but for one i really did not make that |> error (!), and then i also find it absurd to claim to offer |> a timezone interface that covers all the date and time data, and |> then to exclude backzone. | |I think we need, as some have suggested, to figure out what to do about \ |pre-1970 data. I think that includes somehow making it clear that \ |people who expect complete, accurate, and unchanging pre-1970 data \ |are expecting something that | | 1) is currently self-contradictory (Do you want "accurate" or do you \ | want "unchanging"? Some of the data we have is probably inaccurate, \ | so that making it accurate will involve change!) | | 2) would involve a lot of effort (sometimes it's even hard to get \ | information about upcoming time changes from governments; finding \ | historical information might be a lot harder, especially to people \ | who aren't familiar with the language and culture of the location \ | for which you're trying to get historical time information). | |It also includes deciding whether to offer all the data by default \ |(as in "not in backzone"), to provide a way to offer both sets of data \ |separately, or whatever. My personal opinion is that data should not be splitted at all. Instead tooling should be used to cut where the line, if any, is drawn, the make file is capable of doing this. Without being able to quote now, IANA TZ is supposed to offer post-1970 data by default. |> On the other hand the announced release strategy felt offending to |> me. | |I think that given the current level of controversy, the next release \ |should be "2021a+Samoa and any other updates" rather than "current \ |tip of the main branch", so that we get something out that includes \ |the Samoa updates but doesn't include the controversial changes. Or the build should be changed to either cut the data by default, or to include backzone by default. In both cases all but a surely unused broken interface of two downstream libraries should not recognize a difference, .. unless they want to use date pre 1970. It is just sad that for black and other coloured noone spoke up against splitting to backzone, but suddenly it is shaking. Given the length of the thread, maybe your way is the best. But if the year long and now standardized way is continued, including the release, then downstream consumers should be made aware of changes, like letting an unchanged build recipe fail. --End of <B97CABBF-BFEA-4CE5-9D05-9663170ABBE0@sonic.net> --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)