<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body dir="auto"><div dir="auto">I was be contributing a longer message on this whole subject within a few days, but I want to state upfront that country/city is insufficient in many countries for a fully expandable location database.</div><div dir="auto"><br></div><div dir="auto">Off the top of my head, I can think of three different Richmonds in Canada. One in Quebec, one in Ontario, and one in BC. I know there are many Springfields in many USA states, and let's not even talk about the potential USA/Columbus.</div><div dir="auto"><br></div><div dir="auto">The key of a database should be unique and recognizable. For many countries, multiple levels of government are the only way to properly differentiate cities.</div><div dir="auto"><br></div><div dir="auto">Canada/British_Columbia/Richmond would be more appropriate.</div><div dir="auto"><br></div><div dir="auto">This allows the pre-1970 db to be both infinitely expandable, as well as user friendly to the point of being fully obvious to all users.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div id="composer_signature" dir="auto"><div style="font-size:85%;color:#575757" dir="auto">Sent from my Galaxy</div></div><div dir="auto"><br></div><div><br></div><div align="left" dir="auto" style="font-size:100%;color:#000000"><div>-------- Original message --------</div><div>From: Brian Park via tz <tz@iana.org> </div><div>Date: 2021-11-05 11:27 (GMT-05:00) </div><div>To: Philip Paeps <philip@trouble.is> </div><div>Cc: Stephen Colebourne <scolebourne@joda.org>, Time Zone Mailing List <tz@iana.org> </div><div>Subject: Re: [tz] Pre-1970 data </div><div><br></div></div><div dir="ltr"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">On Thu, Nov 4, 2021 at 10:11 PM Philip Paeps <<a href="mailto:philip@trouble.is">philip@trouble.is</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">On 2021-11-05 12:17:34 (+0800), Brian Park via tz wrote:<br>
> I get the impression that this debate is caused by the existence of 2<br>
> different schools of thought: [...]<br>
><br>
> I want to suggest that it may be possible for these 2 views to <br>
> coexist.<br>
<br>
They de facto coexist right now. The overwhelming majority of the data <br>
are descriptive. Only recent efforts have made some of the post-1970 <br>
data appear more prescriptive.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">They coexist in an ad hoc manner right now, and that seems to be one of the causes for the contention. I am suggesting that we formalize the separation, so that both groups are happier.<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
> We<br>
> could create a new file, e.g. call it 'countryzone', which contains a <br>
> set<br>
> of Links organized in a hierarchical tree by country, pointing to the <br>
> Core<br>
> zones.<br>
<br>
I strongly believe we should continue to carefully avoid attempting to <br>
group data by country. [I would even avoid using the word "country" <br>
wherever possible.]<br></blockquote><div><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Can you explain why? Because it will cause arguments about disputed places? I think only a small minority of places around the world are disputed. By separating these ISO-country timezones into a 'countryzone' file, perhaps we can confine the debate into a smaller section of the TZDB. We could
create duplicate entries (i.e. Country1/City, Country2/City), or create a
pseudo-country called "Disputed" (i.e. Disputed/City). The point is, we can create policies that govern these disputed regions.<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Could we move 'countryzone' into a separate project? Probably, but some amount of initial coordination and refactoring would be required to resolve conflicting zone identifiers.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Overall, I feel like the TZDB data should lean a bit more towards matching how end-users think about timezones in the real world (Prescriptive), and lean slightly less on treating timezones as a clustering problem (Descriptive). But I can see pros and cons of both approaches. Which is why I am suggesting ways to make the 2 approaches interoperate better.<br></div></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
> For the pre-1970 data, it is my understanding that the 'backzone' file<br>
> contains Zone records which should replace ONLY the LinkMerged records<br>
> found in the other files. I propose that all LinkMerged records be<br>
> extracted into a separate file (let's call it 'mergedzone') so that <br>
> there<br>
> is a clear symmetry between 'backzone' and 'mergedzone', which allows <br>
> them<br>
> to be substituted for each other. The dependency diagram looks <br>
> something<br>
> like this:<br>
<br>
As I've suggested before in another thread, I think we should consider <br>
undoing the split into backzone. I really liked Stephen's phrasing <br>
earlier in this thread: acceptably accurate, not outrageously wrong. We <br>
started moving data to backzone to limit the scope of 'active' <br>
maintenance to post-1970 data. That artificial split led us towards a <br>
more prescriptive worldview. It seems clear that prescriptive simply <br>
does not work for a real world with people on it.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I think Paul Eggert has made it clear that he does not want to maintain this data. My proposed refactoring of this info into the 'backzone' / 'mergedzone' pair makes it easy for downstream libraries to add back the 'backzone' data if they want. The 'make PACKRATDATA=backzone' hack does not help downstream libraries which do not use TZif or the Makefile.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
> If there is any chance that this will result in being able to type<br>
> "Canada/Toronto" instead of "America/Toronto", that would resolve an<br>
> annoyance that has lasted some 30-35 years.<br></blockquote><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
In this context, America refers to the landmass, not to the political <br>
entity occupying a large chunk of it. [Canada/Eastern etc moved to <br>
backward around 1993, as far as I can tell.]<br></blockquote><div><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Virtual no one in the world thinks of "America" as referring to all of "North America" and "South America".</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Brian<br></div></div></div>
</body></html>