Re: [Tzdist] [tzdist] #32 (service): managing historical data

[Lester Caine <[e-mail]>]

On 24/10/14 17:13, tzdist issue tracker wrote:
>  Looking for elaboration from Lester on this point, as well as whether it
>  needs into a base spec.

The current problem with maintaining historic data is that while most
sources of TZ are reasonably similar, there is a lack of clarity at
times as to just which version of data is being used. In order to review
legacy material it has at times been necessary to reverse engineer the
correct view of the data used. Which is one of the reasons I've been
building a selectable database of tz data. UTC normalized data has been
in use for some time, but exact local time it was normalize from may be
difficult to establish.

Once a more reliable source of data is available it should be easier to
maintain this type of material going forward, but it is essential that
having used a current version of the tz data it is possible to recall
the same view of the data in order to work with the same local offsets
that the data was created with.

Since there are only ever perhaps 1 update per month, there are only a
small number of versions of data to keep track off, and on the whole the
majority of TZ records never change, so only a small set of differences
need to be managed. Adding a version field to the url structure solves
the problem, and would allow material being processed to be tagged with
the appropriate data version.

I would probably view this as optional, EXCEPT that if one takes the
situation of a simple device which is also creating a log of it's data
now correctly using UTC timestamps, it also needs to log any change in
version of data set used while creating that log. To that end even a
simple device only perhaps using 'expand' to obtain its local time data
needs to be able to provide a monitoring site with the correct set of TZ
data with which to view the file. Encoding TZ data into the timestamp
simply does not work, a separate cleanly defined TZ id is essential,
especially when one starts looking at a mobile device moving between
timezones.

( I'll rework the other thread about 'generic' TZ datasets in order to
hopefully explain that side of the problem better, although I did think
it was already pretty good )

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