[tz] Info regarding TZ database
lester at lsces.co.uk
Tue Dec 16 14:05:33 UTC 2014
On 16/12/14 13:38, Paul_Koning at Dell.com wrote:
>> tzdist is a working group of IANA currently trying to formalise an API
>> > to allow TZ data to be supplied as a service. There are demo servers but
>> > nothing has been formally published yet.
>> > There is a bit of a sticking point at the moment as to whether the
>> > service needs to worry about the 'version' of TZ data served up, and the
>> > original draft simply assumed that the latest version of TZ is all that
>> > is needed, but I have a problem with that since material published today
>> > using today's version of TZ may be broken if a later version is used
>> > without any means of identifying the fact.
> “without any means”? But there is a means, that’s why all well-designed protocols have version numbers. Any valid tzdist proposal would have to include the tzdata version designation as part of what it provides.
> There is a separate possibility that some tzdist client might get confused by a new tzdata entry, but that’s mostly the client’s issue, and possibly tzdata, it has nothing to do with the distribution protocol.
> Or are you arguing that tzdist should be a mechanism for distributing obsolete data, alongside current data? Clearly it could be, but I would be surprised if there were significant interest in that.
Your 'obsolete data' is my information to work with material that was
created contemporary with it!
There have been substantial changes to TZ since it's first publication.
Some material has now been proven to be inaccurate, and even current
predictions of changes next year may well be subject to corrections
while current timetables are still showing the currently 'correct'
offsets. So even moving forward being able to see that a calendar is
using 2014j and Paul as just published 2014k with a correction for some
DST changes which affect that data needs access to more than just
Even where one can establish that some historic archive was created
using a particular OS and a version of TZ from that time, the exact data
may well not match that listed in the TZ versions of the time. THAT is
the problem I was trying to resolve a few years back, and is critical to
allow any genealogical material to be maintained into the future without
having to renormalise the data every time a new version of TZ comes out.
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