Stephen Colebourne <scolebourne@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@stanford.edu) <http://www.eyrie.org/~eagle/>