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.]