On Thu, 10 Jun 2021 at 18:37, Paul Eggert via tz <tz@iana.org> wrote:
On 6/9/21 2:41 PM, Stephen Colebourne via tz wrote:
It would be clearer to place an explicit statement in the charter or theory file.
Sure, we could make this statement a guideline in the theory file (that's where the guidelines are) instead of just a NEWS entry. Would that do?
If a statement is to be made it should be in both news and theory.
(And ISO 3166 does have a country code for Kosovo, so even the country-code issue can and plausibly will be disputed.)
I can't find evidence to support that. Kosovo is not present in the official ISO browser tool. There is a code that is being used by some for Kosovo, but it isn't formally endorsed by ISO: "The code XK is being used by the European Commission,[25] the IMF, and SWIFT,[26] CLDR and other organizations as a temporary country code for Kosovo." https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#RS
Once the premise is accepted that the backzone data is a meaningful part of the project
Nobody is saying backzone is meaningless. However, it doesn't logically follow that because backzone has meaning to some, it must be used by all; or even that backzone should be maintained to the same standard as the mainline data (which it's not).
Being lower-priority isn't the same as being frozen: as I wrote last week <https://mm.icann.org/pipermail/tz/2021-June/030181.html> we can take good patches for 'backzone'. Goodness knows it needs them; it has too many errors and inconsistencies and unfairnesses.
"maintained to the same standard" is a phrase that provides confusion. There is no guarantee that the history of a zone in the main files is correct. In fact, much of the data in backzone is more correct than that in the main files. If all the data in backzone had been left in the main files, no one would have batted an eyelid - its just more data about timezones. As a reminder, what I object to is for users of TZDB Europe/Oslo to get any data from Europe/Berlin. Or for users of Europe/Amsterdam to get any data from Europe/Brussels. Your proposed compromise is not acceptable on that basis. Only two solutions appear acceptable to me - no pre-1970 data in the main files (*all* pre-1970 data would be in separate files, and opt-in) - revert the patch and any previous patches that merged zones across country borders But these solutions should apply to all users (not just the ones I represent). The basic idea that you take an ID for one place and get the pre-1970 history for somewhere completely different (in a different country) isn't tenable for TZDB however much you might wish it was. Given your unwillingness to accept that merging timezones across country boundaries is unacceptable, perhaps it might be more fruitful to explore whether the TZDB community would be willing to accept the other option - no pre-1970 data in the main files? Stephen