[tz] attic data for the tz database

Stephen Colebourne scolebourne at joda.org
Thu Aug 29 23:06:32 UTC 2013

On 29 August 2013 21:18, Paul Eggert <eggert at cs.ucla.edu> wrote:
> On 08/29/2013 12:33 PM, Stephen Colebourne wrote:
>> the users I represent don't care about the accuracy, but
>> they will care if it is made willfully inaccurate.
> I'm afraid I don't follow.  As we've seen, similar changes have been
> made to the tz database regularly, and evidently those users didn't
> notice or care.  What's different about these changes?

Firstly, there are a lot of recent changes. Secondly, some of them are
more political than in the past, notably cross border.

I can't say without a lot more research whether, and to what degree,
the previous changes caused visible changes in the historic data of an

>> A comprehensive solution might be two sets of files, one pre and one
>> post 1970 with enough notice for everyone to be able to adapt.
> Yes, though I'm hoping we can be a bit more flexible, with settable
> cutoff dates, something along the lines that Zefram suggested.

Just to emphasise that anything coded in zic is not of use to me or
those I represent directly. Any change that requires filters means I
have to expend effort to fix code implemented in three other places,
one of which (the JDK) is getting more restrictive before its main
release to 9 million developers.

As part of this debate, I have wondered if I should be looking at
bypassing the tzdb and making up our own zone ID system for Java, due
to the apparent instability here. Its really, really not something I
want to see happen however.

I would therefore offer a simple suggestion: Add a "historical data
reliability" indicator to each zone. Say, the earliest date from which
the data is regarded as being acceptably reliable. For London it would
be right back to the start of zones (ie. excluding LMT), but for other
zones it might only be 1970. This would give a solid basis for
filtering, rather than an arbitrary one, and not require any change to
the main data (other than retaining it and not deleting it or moving
it elsewhere).

For the record, I'm not that interested in resurrecting long dead
data, just ensuring that nothing more is lost. In data creation terms,
the proposal email outlines what would be necessary - at least one
full history time-zone per ISO3166 code.


More information about the tz mailing list