[tz] Merged 1970+ time zones should always return -1 pre-1970

[Brian Inglis]

I think for all zones with data merged prior to 1970, the data and API 
should always return *-1* for all times prior to 1970-01-01 00:00:00Z, 
as anything else is inaccurate or a kludge.

Arbitrary disposition of any valid historical data is itself really 
political, for ease of administration, not really technical.

I firmly believe that no decision on the list has ever been made on a 
basis of in-/equity or un-/fairness, as those would be political 
decisions, and we have bent over backwards for years to avoid any such 
appearance never mind actuality, devoting probably the majority of the 
volume of posts and the majority of the volume of words to such 
discussions.

I have always taken the position that any churn not necessitated by 
changes on the ground (or government offices) is detrimental to the 
project and the database, and places a massive burden on downstreams who 
make good use of that data, including the CLDR and ICU projects, 
astronomy and astrology applications, all facets of the transportation 
industry, the databases they maintain, and the storage of what was the 
truth at a previous point in time, and future application uses of that 
previously stored data.

Any such churn should be mediated by the request the list makes of time 
zone decision makers: to provide adequate notice of such changes, at 
least six months, preferably longer.

I can only believe that the adminstrators of this database are under 
some form of political pressure (perhaps /only/ "vitriol in private 
email", which appears to be nearing the norm in certain arenas) to 
dispose of some data to achieve some misguided form of "equity" and 
"fairness", in response to some misguided perception of "inequity" and 
"unfairness" that is not apparent to members of this mailing list, and 
from the reactions, nor does it appear to have been adequately or 
clearly expressed in a form that members of this list can readily 
comprehend, nor is it clearly exactly when these political terms entered 
the discussion, nor what business they have being in it.

As in any project where decisions are questionable, it is necessary to 
back off making any!

The proposers of drastic changes need to enunciate clearly:

* exactly what technical problem they perceive, and why it appears to be 
a problem;
* some alternative options for technical solutions and/or approaches to 
address the technical problem;
* how each alternative option for technical solutions and/or approaches 
to address the problem will satisfy the majority of needs of the 
majority of the stakeholders, and impacts on those unsatisfied;
* why they think the option they propose to adopt is the best and most 
comprehensive solution to address the problem, and satisfies the most 
needs of the most stakeholders.

This is standard practice in most commercial projects.
It is often used when stakeholders can not quickly make a decision, 
decide on policy, or easily change policy.
It allows development to proceed in parallel on all the offered options.
When stakeholders finally decide or act, perhaps months along the 
timeframe nearing release, the selected option can be preferentially 
enabled, possibly with only minor tweaks or just data changes, and 
quickly regression tested to ensure the effect is precisely as desired.

Of course, the best decision to satisfy the most needs of the most 
stakeholders is often the decision to just say "NO !" ;^>

-- 
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.
[Data in binary units and prefixes, physical quantities in SI.]