[tz] McMurdo/South Pole

[Stephen Colebourne]

On 23 September 2013 03:48, Meno Hochschild <mhochschild at 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