[tz] New 'Theory' section "Accuracy of the tz database"

[Lester Caine]

What a waste of a morning. Changing the motherboard only took 30 minutes, but 
I'm 3 hours into getting 'vista' running again ... unfortunately need that for 
the accounts software - and I need to get an end of year run :( Oh for the time 
when I can use Linux software and still keep the accountant happy :(

Paul Eggert wrote:
> Good idea.  I pushed this patch.  This affects only commentary,
> so it should be safe.

Nice summary of the state of play ...
But I feel that the 'problem' of managing what good history is available is 
still being brushed under the carpet ... hoping it will go away?

Filtering the data before building a post-1970 POSIX based 'clock' is fine, and 
that is what is currently being targeted. One thing that comes to mind though is 
that currently I'm seeing 'summertime' transitions prior to 1970. Derick has 
confirmed that he is using the binary data to build the PHP libraries, so 
presumably these are currently included? What will the situation be post the 
'post-1970 only' clean-up? Will these be dropped back to a simple time offset? 
It's a bit like the problem of identifying which version of tz data is being 
used so you know that it may be out of date, but there may be two versions of a 
new distribution?

As I have said, I don't use 'seconds' as my time base anyway, so processing 
leapseconds is just a matter of using 1/86401 on a leapsecond day rather than 
1/86400 so I'm also not restricted when it comes to fractional seconds. So it 
would complete the picture if the rare rules like the Netherlands could be 
incorporated while not affecting the base POSIX rules? It is almost a case that 
'extended mode' should support fractional seconds anyway?

Working mainly from database stored material, the concept of 'NULL' as an answer 
has a number of advantages, but is not practical when using numeric based 
results. I keep coming back to some sort of 'timezone' result which is in 
essence 'NULL' such as any LMT results can be taken as 'can be recalculated 
using local location data' while 'LMTZ' indicates a documented local standard. 
This removes the need to create any new timezones for what is essentially 
outside the scope of the 'default' TZ distribution?

Given that the theory file contains additional documentation on the content of 
the 'data' package, would it not make sense to to include it with that package?

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