Stephen Colebourne wrote:
Sorry to be unsubtle, but I think we're approaching vote of no confidence territory here.
I, for one, continue to have confidence in Paul Eggert's maintainership. On zone.tab he's reached a good compromise, which reduced the political pressure while avoiding throwing away the bulk of useful data. On pre-1970 data, throwing away all pre-1970 distinctions obviously isn't going to fly, and Eggert has already acknowledged this and is modifying his approach. He is responsive to the discussion on the list. My opinion on pre-1970 data is that I'd rather not lose any of the data the project has collected, but the stated scope of the tz project does have effects that can't be ignored. If you want proper handling of pre-1970 timestamps then the tz database isn't sufficient: the zones that it distinguishes pre-1970 are a matter of historical accident, not any systematic treatment. The zones whose conversion to links Paul Eggert has proposed are indeed an anomaly. There should be some project that tackles pre-1970 timezones systematically. My preference would be for the tz project itself to do this. It could be done gradually, by first permitting new zones (for which there's decent data) to be added that differ from existing ones only pre-1970, and eventually by progressively reducing that 1970 threshold to increase the project's formal scope. This is essentially the opposite of Paul Eggert's approach to resolving the anomaly. Another sane option is to limit the official tz database to zones that are distinct post-1970 and have a separate project develop a larger database that takes the more inclusive approach. Or a middle course is to maintain both collections in the tz project with a two-tier structure, the larger database being installed only where specifically requested. The "attic" concept is a step in that direction. Any proposal for a tz database of wider scope has to deal with the technical effects of a larger collection of zones. The compiled tzfiles (and to a lesser extent the source files) don't share data representation between zones, so twice as many zones means twice as much disk usage. Selection of a timezone for present-day purposes is hampered by the existence of multiple zones that don't differ recently enough to matter. There are ways to fix these problems, of course, but they mean that the database can't just be casually expanded. Hence the sense of a two-tier structure. So, in summary: if you want proper handling of pre-1970 timezones then you want something that the tz database doesn't supply. We need some other kind of effort to supply it. And how that effort relates to the present tz project, from among the sane options, isn't a matter for no-confidence votes. -zefram