<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body dir="auto"><div dir="auto">I believe you are missing an important part of this discussion.</div><div dir="auto"><br></div><div dir="auto">There is a strong need for a repository of pre 1970 data, especially for historical research applications. As this is the only tz database, tz has also become the main database for this older data.</div><div dir="auto"><br></div><div dir="auto">For any populated place on earth researchers need such a repository. If I want to add the pre 1970 tz history for Ottawa Canada where should it be stored? Since it is called tz, and it also has other pre 1970 data, tz seems the appropriate place.</div><div dir="auto"><br></div><div dir="auto">But if no simple method of adding open-ended historical data is negotiated here, then the only other option is to fork tz and work on it as a separate project.</div><div dir="auto"><br></div><div dir="auto">Secondly, since the number of locations that could eventually be supported in a historical tz database is potentially very large, it cannot not be micromanaged, and this suggests that each historical zone should use an international standard for naming - iso - for simplicity and clarity.</div><div dir="auto"><br></div><div dir="auto">Canada/Ontario/Ottawa</div><div dir="auto"><br></div><div dir="auto">Are we going to have two tz databases, or just one. That is the question here.</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: Steffen Nurpmeso via tz <tz@iana.org> </div><div>Date: 2021-10-07  09:35  (GMT-05:00) </div><div>To: Stephen Colebourne <scolebourne@joda.org> </div><div>Cc: tz@iana.org </div><div>Subject: Re: [tz] On ISO country for timezones (Re: Classifying IDs) </div><div><br></div></div>Stephen Colebourne wrote in<br> <CACzrW9Cau-q2e+yoBcg=7Rztu19zZN582Xca9ZMYbz=H_0iOpw@mail.gmail.com>:<br> |On Thu, 7 Oct 2021 at 07:08, Watson Ladd via tz <tz@iana.org> wrote:<br> ...<br> |I agree with backwards compatibility. The primary concern here is<br> |whether an ID is considered deprecated or not.<br><br>IDs shall be stable and not change at all.  At maximum they should<br>be moved to backward, for example if a zone is renamed (which may<br>happen for example for Ukraine in a not too distant future, if<br>that is still necessary then, and it looks as if it would be).<br><br>I would always have been all for making infinite stability of IDs<br>a documented assertion.<br><br>Even if not, your "six months" claim is nothing but an aggressive<br>statement.  I think this entire thread is shadowboxing and noise<br>for nothing.<br><br>Looking at the interface of your JAVA framework i think getID()<br>should simply return the correct ID, which may be a link if it is<br>one, and just in case this is not what getID() already returns.<br><br>In my opinion there are only two problems with IANA TZ and how<br>Paul Eggert manages it as a maintainer.  That is the same Paul<br>Eggert who contributes to this software since 1995, an astonishing<br>26 years.  Corroding the maintainership with a continuous stream<br>of noise is disgusting.<br><br>The first is combining of datasets to equal-post-1970 bundles,<br>which is going on for many years.  But the data is there, it is in<br>backzone, and everybody can easily install a complete TZ DB on<br>one's own request.  Yet noone did, even though many packagers are<br>on this list.  This is schizophrenic.  But maybe it is only<br>because of black and yellow people do not matter as much as some<br>blue-eyed white people from northern Europe, which does not truly<br>come as a surprise given the audience who possibly reads this now,<br>and given the fact that colonianisation ended only about 55 years<br>ago, and de facto was only turned from armed political to armed<br>material oppression.<br><br>The second is that documentation did not follow suit the code<br>improvements, as has been recently shown for tzselect(8) and the<br>-t option.  That tzselect(8) uses the administrative zone1970.tab<br>and not the end-user-preferrable zone.tab is a different thing.<br><br>If you want to enforce upon the maintainer of the TZ database that<br>the pre-1970 data is joined back into the normal data, or that<br>"backzone" is splitted into "backzone" and "unreliable", and/or<br>that "backzone" is included by default, and/or that "ZFLAGS='-r<br>@0'" is made default, then create a thread and try to gain enough<br>hums, but please stop this subversion by spreading uncertainty and<br>that even upon topics which never were under discussion as far as<br>i know, and i also read this list for a decade now.<br>It must anyway be said it was nicer once i only had the<br>distribution and did not know about the list :)<br><br>Ciao from Germany,<br><br>--steffen<br>|<br>|Der Kragenbaer,                The moon bear,<br>|der holt sich munter           he cheerfully and one by one<br>|einen nach dem anderen runter  wa.ks himself off<br>|(By Robert Gernhardt)<br></body></html>