[tz] [PROPOSED] Rename internal identifiers to match RFC 8536

[Brian Inglis]

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.