[tz] Regression Tests and Revision Controls

Lester Caine lester at lsces.co.uk
Mon Aug 11 08:39:54 UTC 2014

On 10/08/14 20:14, Paul Eggert wrote:
> Because the tz database is so small and stable that it's feasible for
> one very-part-time volunteer to merge everything into a single branch
> that's almost always near production quality, tagged branches wouldn't
> bring that much to the table.  It'd of course be OK if contributors
> wanted to take the time to make a tagged branch for each potential
> change, but as far as I know no tz contributor does that now and I'd
> rather not impose that kind of version-control bureaucracy on future
> contributors (including myself :-).

Modern tools allow a lot more analysis than used to be possible, and as
well as the github view, there are other projects with clones of that.

The next step is to provide the data with a different view, and that is
one where one can simply plug in a version id and pull out data for that
version. I don't think any of the current third part sources have that
capability? This would make managing the historic data a little easier,
but in reality that is dwarfed these days by the annual changes going
forward ... Recording the tz version with a timestamp only works if one
can then decode it and update it if required. My own Hg DVCS view allows
me to step through the history of file changes so Ican check this
manually but I'm back to the point I was at several years ago where I
want the data in a relational database with a version tag, and all I
need to add IS the diff's each release ...

For some historic offsets we do need to indicate a level of uncertainty,
which is why I was saying 'unknown' at which point the comfortable
offset comes purely from it's location. That tz provides a mean offset
with perhaps an hour or more window is the point here. If a location is
using time based on a central clock rather than LMT then there can be a
substantial change in offset. There was a discussion about the shear
volume of data that could be added but recording when a particular
location came into a tz entry is something that needs to be recorded
outside of tz? It's only the evolution of those tz's themselves which
forms part of the 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 mailing list