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.