[tz] Adding verified historic details

[Guy Harris]

On Sep 4, 2013, at 4:22 PM, Lester Caine <lester at lsces.co.uk> wrote:

> Guy Harris wrote:
>> What about locations that are in a single tzdb zone, so that they currently don't differ in post-standard-time, but that we discover didn't all maintain the same GMT offset subsequent to the adoption of standard time or didn't follow the same rules for "shifted time" (to avoid the term that implies that daylight is being saved and the term that implies that this shift only happens during the summer :-))?
> If the system can't currently handle a fact it needs fixing so it does.

Even if the fix involves splitting tzdb zones and creating new tzids for the new zones?

>>> >If there is documentary evidence of a different time pattern such has been added for the Isle of Man and is about to appear for the channel islands then it should be allowed not blocked.
>> As,*for those locations*, that creates no new tzids (there were already tzids for the Isle of Man and, that's fine with me and, I suspect, Paul.
> But why should what facts are allowed be restricted by some 'mistake' in the past? A fact is a fact ...

Yes, but facts can also be ignored by declaring them "out of scope" and not promising to provide correct time conversions for times prior to 1970.

If you're really suggesting that there not be any restriction on adding new tzdb zones due to pre-1970 differences, then, *if* there is ever a case where correcting the historical data in the tzdb requires splitting a zone (rather than, say, just turning a link into a separate zone, as is the case for the Isle of Man and Channel Islands changes), then either

	1) you'll have to convince the tzdb maintainer to allow that

or

	2) you'll have to fork the tzdb into your own database.

It may be that, with tools to allow a packager of the tzdb to winnow out changes that they view as "out of scope", so as not to have to force users to choose between zones when, for their purposes, the two zones act the same (as I suspect would be the case for many pre-1970 differences on many UN*X systems), the tzdb can maintain the history, and add new tzdb zones as necessary, without inconveniencing all its users.

>> If, however, we were to discover documentary evidence that, for example, some towns in New Jersey chose not to adopt daylight savings time in 1918:
>> 	https://en.wikipedia.org/wiki/1918_Standard_Time_Act
>> supporting*that*  in the tzdb would require splitting America/New_York and creating a new tzid or tzids for those towns.
> 
> NOT supporting a fact means that anybody who is looking for the correct historic data is not going to get it.

People looking for correct historical data in the tzdb need to start by reading the Theory file and, in particular, the

	Clock transitions before 1970 are recorded for each such location,
	because most POSIX-compatible systems support negative time stamps and
	could misbehave if data were omitted for pre-1970 transitions.
	However, the database is not designed for and does not suffice for
	applications requiring accurate handling of all past times everywhere,
	as it would take far too much effort and guesswork to record all
	details of pre-1970 civil timekeeping.
        
	As noted in the README file, the tz database is not authoritative
	(particularly not for pre-1970 time stamps), and it surely has errors.
	Corrections are welcome and encouraged.  Users requiring authoritative
	data should consult national standards bodies and the references cited
	in the database's comments.

part of the Theory file, and realize that there is no guarantee that you're getting correct historic data.