On 2019-06-16 13:14, Paul Eggert wrote:
Internet RFC 8536 uses names that differ a bit from the names historically used in tzdb. The RFC uses "utoff" instead of "gmtoff" for UT (GMT) offsets, and "desigidx" instead of "abbrind" for designator (abbreviation) indexes. Going forward it’s better to stick with the RFC terminology in internal identifiers. This change does not affect longstanding and standard APIs such as the tm_gmtoff member of struct tm or the string "gmtoff" in zdump output. * africa, antarctica, asia, australasia, backzone, europe, factory: * northamerica, pacificnew, southamerica, systemv, tz-how-to.html: * tzfile.5, zoneinfo2tdf.pl: Use UTOFF instead of GMTOFF in comments. * localtime.c (struct ttinfo): Rename tt_gmtoff to tt_utoff, tt_abbrind to tt_desigidx, tt_isgmt to tt_ttisut. * localtime.c (init_ttinfo, tzloadbody): Rename locals for consistency. * tzfile.h (struct tzhead): Rename tzh_ttisgmtcnt to tzh_ttisutcnt. * zic.c (struct rule): Rename r_todisgmt to r_todisut. (struct zone): Rename z_gmtoff to z_utoff. (ZF_UTOFF): Renamed from ZF_GMTOFF. (ZFC_UTOFF): Renamed from ZFC_GMTOFF. (utoffs): Renamed from gmtoffs. (desigidx): Renamed from abbrinds. (ttisuts): Renamed from ttisgmts. (inzsub, stringrule, outzone, addtype): Rename locals for consistency. Traditionally projects strive for stability to maintain robustness in code and data, rather than arbitrary mass changes that increase confusion and reduce understanding.
I really think the existing code, data, and docs are currently definitive, and changing an existing de facto standard to match a proposed RFC is going the wrong way around. Docs based on tzfile(5) and the tz data and API are spread globally across many systems and distros, available translated into many local languages, and used as a basis for operating system infrastructure, that tries to maintain interface and API stability across decades, as they know their code is used as a basis for production systems, which are ideally little changed at their base over years. Many systems base their code on the reference code provided, and globally changing arbitrary identifiers make it much harder to merge changes downstream. Downstreams often maintain patches to revert needlessly disruptive upstream changes so that downstream changes can be minimized to maintain stability. You really need to start considering the downstream global impact of changes you make will have on production systems; the costs to all those organizations and companies of making changes, rebuilding, retesting, and requalifying their applications and operating systems, to ensure continuing function and conformance. Testing changes to be made to production systems are so mentally and labour intensive, for preparation and checking, and multiply by large factors downstream, that costs are high. Any system containing parts of the reference code or data, which has previously been tested to conform to some national or international standard, including for life safety or national security, that is changed to incorporate the new code and data, becomes no longer conformant to any previously tested standard, and has to be totally redocumented and retested from top to bottom, across all functions, to ensure that it still meets those standards. [And if you think desigidx is a more meaningful identifier than abbrind, there is something wrong: I have 26 better choices for sale cheap ;^.] -- 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.