On 6/17/19 8:50 AM, Brian Inglis wrote:
Many systems base their code on the reference code provided
Sure, but the proposed change takes this into account. It does not change any identifier that is external or public or visible to any other part of a system; it affects only internal identifiers. The only names changed were identifiers like "tt_gmtoff" that are visible only inside localtime.c, identifiers like "r_todisgmt" that are visible only inside zic.c, and the identifier tzh_ttisgmtcnt in the file tzfile.h that is prominently marked as being internal to tzcode. Changes to internal identifiers are relatively routine and have occurred over the years without incident; for example, zic.c's internal identifier "puttzcod64" was renamed to "puttzcodepass" in 2019a.
changing an existing de facto standard to match a proposed RFC is going the wrong way around This statement doesn't match the process as I understand it. Internet RFC 8536 was coauthored by Arthur David Olson, Ken Murchison and myself, and its drafting process (which was announced here, was open to all commenters, and which responded to quite a few comments) did its best to come up with regularized names to avoid confusion that is common in this area, confusion that in some cases extended to tzdb itself. The recent changes to what is mostly commentary in tzdb attempts to take advantage of the RFC 8536 work by propagating some of its terminological cleanups back into the code.
In the long run, RFC 8536 will likely be more important than tzcode for parties interested in interoperability, just as Internet RFC 1952 is now more important than the gzip source code for parties interested in developing software that can read or write gzip compressed data. So there should be a long-term benefit to encouraging harmonization between internal tzdb terminology and the RFC's terminology.