[tz] McMurdo/South Pole

[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.