[tz] McMurdo/South Pole
lester at lsces.co.uk
Mon Sep 23 04:57:49 UTC 2013
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
More information about the tz