[tz] Proposed reversions, for moving forward

Stephen Colebourne scolebourne at joda.org
Sat Aug 9 09:33:00 UTC 2014

On 9 August 2014 00:51, Paul Eggert <eggert at cs.ucla.edu> wrote:
> This is based not only our experience with doing
> these tz changes in the past (we've done 'em, multiple times, for many
> years, with no problems reported); it's based also on my experience with the
> few applications that could conceivably use this old data (mostly astrology,
> but also earthquake records and the like)

This is a far too limited view of the usages of the data, perhaps that
is part of the problem here. The reality is that millions of
developers use this old data, it is just indirect rather than direct.

1) Most developers are not aware of the nuances of coding well using
date and time, and especially not times in the past.
2) Java, and many other languages, have a date/time system that allows
any date to be requested, including into the very far past
3) When requesting a far past date, a time-zone offset is associated
with the time in many cases. That offset often will be LMT.
4) When LMT is changed that change is visble.

Saying that the developers are doing it wrong may be true, but it is
also meaningless. We cannot fix the code or mental models of millions
of developers.

We can say that the developers do not really care about the offset
they are given per se, however it is likely that they will not have
explicitly coded for the data to change. Most of the time, it all
works out, but sometimes it won't. Any issues will be handled by
individual developers - we will never hear about them here on this

This is a big issue as the date that is being used as the cutoff date
(1970) is really not that long ago. Many people have birth dates
before that date, and so have the potential to be affected. ie. we are
discussing timestamps of living people (recent changes affected up to
the 1960s).

What we need is a consistent approach to data before 1970 that will
result in stability going forward. If we had that, then a one off
change to reach the stable state becomes desirable, rather than


More information about the tz mailing list