On 23 September 2013 03:48, Meno Hochschild <mhochschild@gmx.de> wrote:
Up to now standard Java-APIs like the class java.util.GregorianCalendar force the users to apply timezone calculations even in use cases where it is not appropriate at all. Example: Calculation of age differences of living persons. While it would be totally okay to base such a calculation on purely julian days without even considering timezone offsets the sad practise is that users have to use a timezone dependent data type to do such calculations. So they often implicitly apply tz calculations and are therefore strongly dependent on accuracy of tz data even pre 1970. Looking at this background it is surely understandable that some java users are now so concerned about newly publicized changes of tz data where they in former times never bothered about it but just took the tz data for granted or didn't even see involved tz calculations in their own software. Well, the new JSR-310-Date-And-Time-API (S. Colebourne is one of the project leaders) has finally introduced alternative types like LocalDate which is independent of timezone data. That is a huge improvement. But unfortunately JSR-310 also continues the traditional way to return *an* answer for ALL times regarding to timezone calculations i.e. does not have a concept of limited validity of such requests - see the new java class ZonedDateTime. Furthermore, the old timezone dependent types in Java will still continue to exist (probably for ever) and are not even declared as deprecated - a huge accident. But for all this stuff, the tzdb itself is not responsible for.
Exactly, recent changes affect the data seen by every Java developer via GregorianCalendar. For JSR-310, there are two separate issues mixed here 1) should a result should be returned using a time-zone for ancient times (pre 1800). ZonedDateTime and GregorianCalendar do so because the only alternative is an exception and that would cause more pain to a typical developer than returning some vague result based on LMT or similar. 2) should a result should be returned for recent history (1800 - 1970). In this case, plenty of developers will be querying local time, for birth dates, historical documents, contracts etc, and they would expect a reasonable answer. It is clear that tzdb data is being changed that affect this period, and thus affecting users. Stephen