[tz] McMurdo/South Pole

[Lester Caine]

Meno Hochschild wrote:
> 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.

A similar situation has now been created in the PHP API, which has also been 
switched to using TZ as the 'bible' when it comes to DST information. So the 
above statement applies ... except that the TZ data needs to return 'invalid' 
when a request is made that it can not process. So that we can then revert to an 
alternate lookup. Alternatively one simply assumes that anything prior to 1970 
is always wrong, and lookup an alternate database anyway?

It may well be that external API's were wrong in adopting TZ as their database 
for DST data if it was never going to support accurate historic data. The 
question is what should be used instead since SOMETHING is required to provide 
that data now that API's have switched to it properly supporting DST. McMurdo is 
a clean example of where pruning pre-1970 data is losing perfectly valid and 
auditable data and other areas which we know that the historic data diverges but 
don't have accurate material for is equally wrong returning data that we know is 
simply an alternate guess. TZ needs to be honest and pre1970 lookups are just as 
valid as post? Even if a lot smaller number of hits require that data.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk