Paul Eggert wrote:
If we relaxed this rule, and allowed multiple regions even though their clocks agreed since 1970, that will be a recipe for more political disputes. For example, why does the Navajo Nation have its own entry while the Hopi Nation doesn't? Or, why does Quebec have its own entry while Prince Edward Island lacks one? Currently, our only real answer is "because we felt like it". That is not a fair answer, and it will inevitably lead to more political problems in the future. Some new rule would have to be created. Defining for instance a degree of accuracy for splitting pre-1970 regions.
Zefram wrote:
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. +1
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. +1
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. This is a technical problem, and suitable for technical solutions. Configuring the package could for instance accept a cutoff date as parameter. So I could configure and install the database with zones for last century, since unix epoch, since I was born, since foundation of the company, since I bought my first computer... Many people don't even need accurate data back to 1970, and Windows is a good example of that. I'm sure I could work with Europe countries being hardlinks to 4-5 files.