[tz] Dealing with Pre-1970 Data
scolebourne at joda.org
Fri Aug 30 21:07:47 UTC 2013
On 30 August 2013 21:10, Guy Harris <guy at alum.mit.edu> wrote:
> If we're obliged to leave them in the tzdb for backwards compatibility purposes, we should:
> accompany them with a disclaimer that they're not actually meaningful, for all the reasons discussed here (not all locations within a time zone necessarily had the same LMT value before the establishment of the zone; different people *in the same city* might have had clocks different from each other by significant amounts; etc.), explicitly stating that supporting conversion of times prior to the establishment of a standard time zone in a locale is out of scope for the tzdb;
> freeze them and devote no effort to updating them;
-1. So long as we have them, there should be a best efforts attempt to
maintain them. Realistically, that only means that any new zone should
have an appropriate LMT set. No more.
> not create any new tzdb zones if the only reason for the new zone is "before standard time was established, these two locations had different LMT".
(just to note that Rome vs Vatican was to fulfil the "full history in
an ISO code" requirement I proposed, not to create unecessary LMTs)
> Historical rules *subsequent to* time zone establishment, however, are arguably worth keeping and perhaps even updating, albeit perhaps with a disclaimer saying we can't guarantee historical accuracy and/or that they are subject to change due to additional historical information being found.
+1. This is the far more important issue.
FWIW, I've started the process of removing LMT from Java JSR-310.
Unfortunately, the option of throwing an error for far past values
(back to the age of the universe) is not an option. I do understand
the weirdness of these far past times, but in the context of the API
it is simply not acceptable to have date-times in the 1700s for
example without any notion of offset from GMT.
More information about the tz