[tz] New 'Theory' section "Accuracy of the tz database"
lester at lsces.co.uk
Sun Sep 15 12:31:49 UTC 2013
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
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
More information about the tz