[tz] McMurdo/South Pole

[Stephen Colebourne]

Just to note that I firmly disagree with this analysis.

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.

For example, someone can use the APIs I write to ask the question
"which locations had DST in 1932?". That answer is now wrong for
McMurdo.

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. I cannot inflict that pain on my users.

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>

Stephen
(BTW, the "everywhere was uninhabited" point does not make sense. An
uninhabited location would effectively be on LMT, so tzdb is accurate
as far as it can be. Only locations like McMurdo change from
unihabited to inhabited at a known date, and LMT should apply before
that date)



On 20 September 2013 17:03, Paul Eggert <eggert at cs.ucla.edu> wrote:
> McMurdo is a special case of a more general problem, which
> is the representation of locations while uninhabited.
> *Every* location in the tz database was uninhabited at
> *some* point, and the tz database does not attempt to
> systematically record the details of when a location
> was inhabited and when it wasn't, as that's outside the
> scope (and the values are typically unknown anyway).
> In practice I've used "zzz" entries for uninhabited
> locations only when the database format *forced* a value.
> When it doesn't force a value I haven't worried about it,
> and I'd rather not start worrying about it now.
>
> There's an amusing instance of the opposite problem in
> Pacific/Johnston, which was inhabited when we created
> the tz database but became uninhabited in 2004.
> Its entry cheerily says "We're just like Honolulu!",
> and really, that's OK: worrying about the discrepancy
> would be more trouble for everybody than it's worth.