[tz] Unacceptable recent changes [wasRe: [PATCH 2/4] Move obsolescent Americas entries to 'backward'.]

[Ángel González]

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.