[tz] [PATCH] Revert recent pre-1970 changes.
guy at alum.mit.edu
Mon Sep 2 18:49:59 UTC 2013
On Sep 2, 2013, at 10:46 AM, Stephen Colebourne <scolebourne at joda.org> wrote:
> In enterpirise development both occur. There are also cases where we
> need to lookup the time-zone by ISO-3166.
By ISO 3166 plus something else, presumably, given that the correct answer to "what are the tzids for country codes US and CA" is "mu!"
> While such a lookup (based on zone.tab) is not in JSR-310,
...and such a lookup doesn't depend on there being, for each ISO 3166 country code, at least one tzid corresponding to a location within that country; there is no *technical* reason why HR couldn't map to Europe/Belgrade. The problems with such a mapping are cultural/political, not technical; this does not mean that we can ignore those problems, it just means that they're not *technical* problems and there is no purely-*technical* requirement that, for each ISO 3166 country code, there be a tzid corresponding to a location within that country. (All problems in computer engineering can, as we know, be solved by adding a layer of indirection. :-))
> 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.
Where "work" is presumably defined to mean "always return a value rather than throwing an exception" rather than "always return a *useful* value", the latter being difficult at best for an instant preceding, say, the Big Bang.
The question is "how far back should that API attempt to provide *useful* values?" If it dates back to before the government of the location for which you're trying to get local time for that instant establishing civil time as being standard time, that gets difficult, and if it dates back to before we currently have reliable information about Daylight Savings Time, it again gets difficult.
*Deleting* historical information makes it more difficult, of course. So does not splitting zones if newly-discovered historical information indicates that two locations within a given tzdb zone had different standardized offsets from GMT or different DST rules. How far should the tzdb go? And should there be a way to generate, from the tzdb, a modified tzdb that coalesces all "different only before 1970" tzdb zones into a single zone? I suspect that, if we have a lot of "different only before 1970" tzids, a lot of UN*X systems will want to coalesce them, to simplify the initial time zone setup process if nothing else.
And, if the Wikipedia article on ISO 3166 is correct, "The first edition of ISO 3166 was published in 1974", so ISO 3166 codes are irrelevant to the historical accuracy of pre-1970 tzdb information in any case - they're not even relevant to post-1970 but pre-1974 tzdb information. :-)
> 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.
"Time zones", in the commonly understood sense, *are* limited to a narrow region of time, dating back to the establishment of said zones. I don't think there were time zones, in that sense, in 1066 CE, for example. About all you can do with a date/time going back *that* far is treat it as local mean solar time or local apparent solar time, and that involves neither time zones nor the tzdb.
More information about the tz