On 2 September 2013 00:34, Guy Harris <guy@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