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

[Stephen Colebourne]

On 2 September 2013 00:34, Guy Harris <guy at alum.mit.edu> wrote:
> 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.

In enterpirise development both occur. There are also cases where we
need to lookup the time-zone by ISO-3166. While such a lookup (based
on zone.tzb) is not in JSR-310, its omission is primarily one of
reducing scope for "version 1". I do expect a future version of the
API to provide such a lookup (ISO-3166 to a list of zone IDs).

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

Java APIs that I look after allow the user to create an object
representing an instant in the far past/future. With JSR-310 that is
up to 1 billion years forward and backward. Obviously, time-zones make
little sense that far out, but the API is designed to make them work.
Such a decision fits well within the overall API and protects users
from boundary bugs which would occur if time-zones were arbitrarily
limited to a narrow range of a hundered years or so around now.

I don't expect anyone who is happy with the detailed meaning of time
and time-zones (such as those on this list) to be happy with such an
API. My target audience is those that just want things to work in an
acceptable and bug-free manner, similar to how it has always worked in
Java.

Stephen