On 29 August 2013 21:18, Paul Eggert <eggert@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 ID.
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. Stephen