<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">On Thu, Nov 4, 2021 at 10:11 PM Philip Paeps <<a href="mailto:philip@trouble.is" target="_blank">philip@trouble.is</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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 style="font-family:arial,helvetica,sans-serif" class="gmail_default">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 style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> 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 style="font-family:arial,helvetica,sans-serif" class="gmail_default">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 style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">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 style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">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 style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> 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 style="font-family:arial,helvetica,sans-serif" class="gmail_default">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 style="font-family:arial,helvetica,sans-serif" class="gmail_default"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> 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 class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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 style="font-family:arial,helvetica,sans-serif" class="gmail_default">Virtual no one in the world thinks of "America" as referring to all of "North America" and "South America".</div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">Brian<br></div></div></div>