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

[Stephen Colebourne]

On 28 August 2013 17:46, Paul Eggert <eggert at cs.ucla.edu> wrote:
> On 08/28/13 09:20, Stephen Colebourne wrote:
>> Many users will have stored data in databases or other
>> long term storage that refers to these time-zones being made obsolete.
>
> The zones are not being made obsolete.  TZ=America/Atikokan
> will still work, and will give the same results as before
> for post-1970 timestamps, which are the only timestamps in
> scope for this project.

Some systems will automatically map the old "backward" forms of IDs to
the "correct" new forms. Thus users will see their Atikokan replaced
by Panama, something which is clearly ridiculous.

The "backward" file is intended for IDs that have been replaced on
spelling or city size grounds, not for IDs which you no longer feel
like maintaining.


> I sincerely doubt that the proposed change will cause any
> problem in practice.  It's simply not the case that "many users"
> have pre-1970 timestamps for Atikokan and will notice or
> care about the proposed change.  After all, the pre-1970 data
> for Atikokan was almost surely incorrect, and nobody cared
> about that either.

Yes, they really do care. By being the world's only real source of TZ
data, the database de facto defines what time was around the world
pre-1970. Clearly you do not like that data as you are treating it
with utter disdain.

The pre-1970 data (for many different zones) is encoded in a vast
amount of systems around the world, in databases and more. Removal, or
otherwise hiding it forces either a fork or your removal.

To be clear. Deletion of that data, or making it far harder to access,
is unacceptable.


> That being said, I do take the point that we should not
> discard the old data even if it's wrong or problematic, so
> I'll work on a further patch that will resurrect it, along
> the lines already suggested.

That isn't good enough.

Sorry to be unsubtle, but I think we're approaching vote of no
confidence territory here. Your actions are causing severe damage to
the database built up over many years, and that cannot be allowed to
stand.

Stephen