Good day My name is Naveed and I have some query regarding the TZ database, is it possible to query the timezone database maintained by IANA or any other possible solution to have a local copy of the same at our own premises, we have to integrate with our in-house application with timezone information. Best Regards and Thank You Naveed Shakur.
Hello, the "TZ database" is not some sql instance somewhere , it's a text based "database" you can download the whole set here http://www.iana.org/time-zones Regards, Gunther On 16/12/2014 6:58, Naveed Shakur wrote:
Good day My name is Naveed and I have some query regarding the TZ database, is it possible to query the timezone database maintained by IANA or any other possible solution to have a local copy of the same at our own premises, we have to integrate with our in-house application with timezone information.
Best Regards and Thank You Naveed Shakur.
On 16/12/14 05:58, Naveed Shakur wrote:
Good day My name is Naveed and I have some query regarding the TZ database, is it possible to query the timezone database maintained by IANA or any other possible solution to have a local copy of the same at our own premises, we have to integrate with our in-house application with timezone information.
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. -- 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
On Dec 16, 2014, at 4:17 AM, Lester Caine <lester@lsces.co.uk> 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. paul
On 16/12/14 13:38, Paul_Koning@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 'latest' ... 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
participants (4)
-
gunther vermeir -
Lester Caine -
Naveed Shakur -
Paul_Koning＠dell.com