[tz] [PATCH 0/2] Follow Australian common usage and update CST/CST to CST/CDT and EST/EST to EST/EDT etc [SEC=UNCLASSIFIED]

[Tobias Conradi]

On Thu, Apr 11, 2013 at 6:53 PM, Dennis Ferguson
<dennis.c.ferguson at gmail.com> wrote:
>
> I would note, however, that the proposed patch doesn't just limit itself
> to reducing the ambiguity of future timestamps not yet recorded,
future and not yet recorded - do you use the terms in a tautological
way? Or would you allow "timestamp" to refer to an existing time
record of a future event?

> it also
> changes the database information about the abbreviations used for historical
> timestamps produced by the TZ database.
Same here, what is a historical timestamp? Does it include a time
record made in 2000 for an event in 2010 and 2020?

>  While the issue of what time zone
> abbreviations people in Australia might have preferred to use is for others
> to debate there can be no dispute about the abbreviations the TZ database
> has used for the last 20 years, nor is there any way to change that,
Agreed.

> but
> by altering that data one is effectively removing the information about the
> history of the database itself
> that one would need to know to interpret
> timestamps already recorded with the "unwitting use" of the TZ database.
The archive is here:
ftp://ftp.iana.org/tz/releases/

Depending on what you mean by time stamp, you would need to know when
the stamping took place.

> Is there a reason to change the historical TZ database abbreviations
> rather than just making a change which is applied going forward?
Yes,
1) make talking about events that happened in the past less ambiguous.
2) applying a change will always have some users stamping with the old
abbreviations and new users with the new ones. So trying to limit a
change to the second of the release does not yield the benefit you try
to portrait.

> You
> can't really fix what has already happened,
But the ambiguity introduced by what happened can be reduced, for time
records of future and of past events.

> and attempting to pretend
> that it didn't happen
No one is attempting that.

> that way just seems to increase the ambiguities that
> people with a need to interpret old timestamps produced with old versions
> of the TZ database need to deal with

So they have 10:00 EST for an NSW place during DST. How did they
interpret it until now, as Summer Time or as Standard Time? What will
be the problem if that is changed to say "EDT"?

> while having no offsetting advantages
> that I can see.
Allow talking without ambiguity about past events.

> As a policy matter I'd prefer that the bar to changing past TZ database
> data was set much higher (i.e. should require evidence of factual errors
> rather than just issues of opinion) than the bar to making changes which
> only effect the future.
Maybe for plain alterations of abbreviations, but for disambiguation,
i.e. splitting A into A and B?

--
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com/