[tz] McMurdo/South Pole

[Russ Allbery]

Stephen Colebourne <scolebourne at joda.org> writes:

> We would not and should not create an ID for an uninhabited location,
> but where somewhere is or was inhabited we should make best efforts to
> define accurate data. The new McMurdo data is clearly not accurate prior
> to 1956.

There is no such thing as local time in McMurdo prior to 1956.  There is
no standard for accuracy; the entire concept of accuracy of such a thing
is meaningless.  Local time is not a physical property.  It's something
created by humans who make shared rules about how to set their clocks, and
in the absence of human presence, it doesn't exist.  Local time in McMurdo
prior to its habitation is undefined.

To use a Java analogy, you're doing the equivalent of complaining that
finalize() isn't running at the point in your program where you expected
it to and where it ran in a previous release of the JVM.  You're getting
about as much sympathy here as you'd get with that plea in a Java
community.

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

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

> The problem I have is that I'm no longer sure I can trust tzdb to safely
> be the guardian of the limited pre-1970 data which it has always
> possessed and which Java has long used. I will be talking to Oracle
> people this week to discuss what options we have for Java probably
> requiring manual workarounds of the damaged data. <shakes head
> in despair>

I once again encourage you to start your own separate project.  I think
that would make quite a few people much happier, including you.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>