<div dir="ltr"><div>On Fri, Nov 5, 2021 at 3:35 PM dpatte <<a href="mailto:dpatte@relativedata.com" target="_blank">dpatte@relativedata.com</a>> wrote:</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"><div><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"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">[...]</span></div><div dir="auto">Canada/British_Columbia/Richmond would be more appropriate. </div></div></blockquote><div><br></div><div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">I think you have a different version of an ISO-country-based timezone database than I had in mind. I was not thinking of a "location database". I think that would be far too difficult. I was  trying to see if we can capture the hierarchy of timezones, as created by governing authorities, starting with ISO countries at the root. So "Canada/British_Columbia/Richmond" would exist only if it  followed a different set of rules than "Canada/Pacific" (and "Canada/Pacific" would be a Link to "America/Vancouver"). The process of splitting timezones would be similar to the one used in the current TZDB project, because the entries in 'countryzones' would simply be Links to the canonical TZDB Zone entries.<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">But as I mentioned in my previous post, I think the scope of this 'countryzone' file is so large, it needs to be a separate project.<br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"></div><br></div><div style="font-family:arial,helvetica,sans-serif" class="gmail_default">Brian</div></div></div>