[tz] McMurdo/South Pole

[Meno Hochschild]

I completely agree with the analysis of Guy Harris and would add 
following notice for participants who are not quite firm in Java APIs.

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.

Summarizing this I get the impression that the whole discussion here is 
mainly because external api problems are projected into the tz mailing 
list. But I think it would be better for external users of tzdb like api 
designers to think for example about new validity concepts when 
formulating requests of tz data. And this mailing list can then simply 
be limited to traditional timekeeping tasks and timezone research. Just 
my 2 coins.

Am 22.09.2013 09:30, schrieb Guy Harris:
> On Sep 21, 2013, at 10:51 PM, Russ Allbery <rra at stanford.edu> wrote:
>
>> As with any situation with undefined inputs, the output is basically at
>> the discretion of the software, and returning either an error or some
>> reasonably convenient answer are both standard approaches.
> I.e., there's limits to the sympathy you're likely to get for a complaint that the software and database changed from returning one technically-incorrect answer to a different technically-incorrect answer.  (I suppose that one might get more sympathy for that than for a complaint that it changed from giving a technically-incorrect answer to a technically-correct answer.)
>
> Anybody who depends on the tzdb to give a technically correct answer for times arbitrarily far back in the past is pretty much *guaranteed* to be disappointed.
>
> Anybody who depends on the tzdb to give a technically correct answer for times subsequent to the official legal establishment of some form of standard time as civil time had better be prepared to be disappointed unless they're willing to put forth the effort to find officially-supported information about civil time in the location(s) about which they care and are willing to live with the results being incorrect until that information is incorporated into whatever version of the tzdb they use (whether that's the official version or their own privately-patched version).
>
> Anybody whose goal is to have their APIs return *an* answer for all times, regardless of whether it's technically correct or not, shouldn't worry that much about the accuracy of the tzdb.
>
>> Personally, I like the idea of returning an error, since I don't like undefined inputs
>> resulting in apparently accurate outputs with no error. But,
>> historically, the code has always returned some arbitrary but vaguely
>> reasonable response (usually either a blind backwards-projection of
>> current rules or whatever was the prevailing time standard in some
>> reasonably nearby location) instead of producing an error, and there's a
>> backwards compatibility challenge with changing that behavior to produce
>> errors.
> +1.
>
>>> The key problem with the change for data consumers is the fact that
>>> McMurdo was uninhabited in the 1930s is *external* information, that an
>>> application would now need to *separately* know in order to get the
>>> correct result for McMurdo.
>> There's no such thing as a correct result for McMurdo in the 1930s because
>> the question is not well-formed.  The application cannot get something
>> that doesn't exist.
> +1.