On 9 August 2014 00:51, Paul Eggert <eggert@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 list. 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 undesirable. Stephen