[tz] [PATCH 2/4] Move obsolescent Americas entries to 'backward'.

Stephen Colebourne scolebourne at joda.org
Wed Aug 28 10:04:00 UTC 2013

The issue is whether all these changes are worth it. What are you
seeking to gain?

There is real value in this database of stability and backwards
compatibility. Changing something because it is "neater" or general
"tidying up" are bad goals here.

For example, changes to LMT definitions (which is what the above looks
like) will have a visible impact on users where LMT is exposed - soon
to be seen by 9 million Java developers.

Also, times before 1970 do matter. Whether you are certain or
uncertain of the data is less important than not changing the data. In
essence the TZDB has become the definition of what time was,
irrespective of whether it is accurate or not. As such, history should
only be changed if it is demonstratable that the original data was

As such I'm skeptical of all recent changes to the TZDB.

co-spec lead JSR-310 (to be used by 9 million Java developers)

On 27 August 2013 19:00, Paul Eggert <eggert at cs.ucla.edu> wrote:
> On 08/27/13 01:18, Derick Rethans wrote:
>> Are you leaving this longstanding policy of data stability behind now?
> Systematic support for pre-1970 timestamps has always been outside the
> scope of the tz database, and as I recall it's been removed before
> without problems.  The intent is that clock transitions before 1970
> are recorded only to fill in the blank areas (on platforms with negative
> time_t) for locations that differ since 1970.  So no, the policy
> hasn't changed here.
> For details, please see "Scope of the tz database" in the Theory file
> <http://www.ietf.org/timezones/code/Theory>.

More information about the tz mailing list