[tz] More irrelevant political disputes about identifiers and labels

[Brian Inglis]

On 2019-06-21 11:17, Oleksandr Ryzhenko wrote:
> By this letter let me as the representative of Ukraine to ICANN's GAC inform you
> about the following.
> The State Agency for e-Governance of Ukraine is the national authority of
> Ukraine that is responsible for matters related to Internet governance,
> including those within the purview of ICANN.

As an ICANN GAC representative you should be aware that RFC 6557 BCP 175
Procedures for Maintaining the Time Zone Database documents the process, be
familiar with its contents, and follow the ICANN, IANA, and IETF processes to
point out where the time zone database contents have not been maintained in
conformance with that Best Current Practice, or discuss in what ways that Best
Current Practice should be modified to allow the database to better reflect the
reality of time zone offsets used in time zones.

The time zone data reflects the reality of time being kept in a zone during a
historical period, labelled by English language ASCII technical directory and
file zone identifiers, which for human convenience may correspond to the most
commonly used historical English language identifiers of representative
geographic entities such as continents, oceans, regions, countries, territories,
or cities, and similarly for English language ASCII technical abbreviations used
after times to label zones where there could be ambiguity in observance or
interpretation.
Note that nowhere are zones defined they are only identified by labels.

Political disputes about identifiers and labels are really *OFF TOPIC* for this
list, and should be kept for more appropriate forums.

As such, political considerations and resolutions by the UN, EU, US, etc. have
no bearing on the contents of the technical time zone data base, except in so
far as UTC offsets of time observed on the ground in a zone, are legislated and
modified by political actions, including territorial disputes including war.
Some historical data has been corrected to reflect the reality of actual time
keeping in zones during territorial disputes and war times.
Most of the disputed information is provided solely for the information and
convenience of humans in downstream projects and organizations.

It is up to downstream projects, applications, systems, distros, organizations,
and vendors which use the data to provide what they consider suitable
localizations in their interfaces which use the time zone data.

Perhaps this would be a good time to reduce the dispute surface by removing all
country codes, all compatibility links, and all English time zone abbreviations,
from all time zone data files, generating POSIX %z abbreviations.

Consideration should also be given to reducing the identifiers to arbitrary
numbered file names: zoneinfo/01-99/0001-9999, where the directory corresponds
to the continent/ocean/region after renaming as numbered data files, and the
zone identifier corresponds to the sequential order of the zone in each numbered
data file.
To accommodate this, null zone entries would have to be allowed to handle splits
or merges where historical information changes.
For completeness, rule identifiers should also be replaced by sequential numbers
within each data file, and to accomodate historical information changes, null
rule entries would have to be allowed to handle splits or merges.

Historical English language ASCII identifiers and labels could possibly be
maintained in the personal experimental github repository, which could contain
scripts to sanitize the data supplied to IANA.
To avoid any possibility of disputes, comments could also be stripped.
If maintaining those historical identifiers, labels, and comments is not
considered desirable, mappings between the time zone identifiers and geographic
locations would be the sole responsibility of downstream consumers.

Alternatively, as time zone data is binary system information essentially
unrelated to the Internet, and the IANA connection seems to be increasing the
irrelevant disputes and politicking on the list, find an alternate host for the
list and the database, perhaps in the non-GNU sections of the GNU organization,
or somewhere more neutral, such as an open source organization or site in
Scandinavia or elsewhere.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.