[tz] [PATCH] Revert recent pre-1970 changes.

[Guy Harris]

On Sep 1, 2013, at 2:47 PM, Stephen Colebourne <scolebourne at joda.org> wrote:

> On 1 September 2013 10:20, Guy Harris <guy at alum.mit.edu> wrote:
>> On Sep 1, 2013, at 1:55 AM, Stephen Colebourne <scolebourne at joda.org> wrote:
>>> ISO-3166 codes are important to the vast majority of actual
>>> applications that care about time-zones.
>> 
>> ..."care about time-zones" presumably meaning "*explicitly* care about time-zones", for example, applications that explicitly specify a time zone (whether wired in, specified as an application parameter, or specified in some configuration file or database for the application), rather than "*implicitly* care about time-zones", for example, the "date" command on UN*X systems, which cares that ctime() will convert seconds-since-the-Epoch to a string giving local time in the user's time zone, but doesn't explicitly request a particular time zone (and which has absolutely no idea what an ISO 3166 country code is, and has no reason to know).
> 
> The applications I work with and libraries I manage allow a developer
> to find the local time and offset from UTC/Greenwich for any instant
> on the timeline.

Where I'm sitting right now as I type this sentence, the local time is 4:24 PM and the offset from UTC is -7:00.

Where some other members of the list, the local time is *not* 4:24 PM and the offset from UTC is *not* -7:00.

Therefore, presumably either

	1) the developer explicitly specifies *which particular* local time and offset they want, which is the "*explicitly* care about time zones" case

or

	2) the developer implicitly gets whatever local time is configured, which is the "*implicitly* cares about time zones" case.

In neither case, if the tzdb is being used, does the developer for case 1) or person doing the configuration for case 2) need to specify an ISO 3166 code for the time conversion, unless the tzid isn't being specified explicitly but is instead being derived from some other values that include an ISO 3166 code.

The applications in question might, for some other reason, use ISO 3166 codes, but that's a separate matter.

And if you mean by "for any instant on the timeline" you mean "arbitrarily far in the past" ("arbitrarily far in the future" is only a guess unless you have an algorithm that perfectly predicts government behavior), then the real problems have nothing to do with ISO 3166 codes, they has to do with

	1) the reliability of historical standardized time information in the tzdb (see, for example, per Paul's comment about Shanks);

	2) the completeness of historical standardized time information in the tzdb (i.e., current tzdb zones might, in order to track standardized time rules all the way back to the introduction of standardized time, need to be split);

	3) handling time *before* standardized time was introduced (which the tzdb can't and shouldn't do).

1) has nothing to do with ISO 3166 country codes.  2) doesn't really do so, either, as a zone that was always part of one and only one country might *still* get split due to, for example, local peculiarities in handling daylight savings time of which we were previously unaware.