[tz] Dealing with Pre-1970 Data

Stephen Colebourne 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;

+1

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

+1

(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.
https://github.com/ThreeTen/threeten/issues/332

Stephen


More information about the tz mailing list