Re: [tz] tzdata 2016g
Susan Abraham wrote:
The DST Patches for Oracle Databases are released based on the tzdata. I got the tzdata 2016g release from https://github.com/eggert/tz/releases.
What are the changes included in 2016g?
The changes are summarized in the NEWS file. https://github.com/eggert/tz/blob/2016g/NEWS
Hi, Why is 2016g tzdata not published on IANA website? On Wed, Sep 21, 2016 at 11:17 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
Susan Abraham wrote:
The DST Patches for Oracle Databases are released based on the tzdata. I got the tzdata 2016g release from https://github.com/eggert/tz/releases.
What are the changes included in 2016g?
The changes are summarized in the NEWS file.
Sowmya Gangishetty wrote:
Why is 2016g tzdata not published on IANA website?
That's been discussed on the mailing list, e.g.: http://mm.icann.org/pipermail/tz/2016-September/024135.html
Hi, Is there any news on this? Any further word from ICANN? Thanks, Debbie Sent from my iPad
On Sep 21, 2016, at 12:37 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
Sowmya Gangishetty wrote:
Why is 2016g tzdata not published on IANA website?
That's been discussed on the mailing list, e.g.:
On 09/26/2016 09:02 AM, Deborah Goldsmith wrote:
Is there any news on this? Any further word from ICANN?
Although the IESG has been pinged about the situation with https://www.iana.org/time-zones, I'm afraid I know of no news yet.In the meantime you should be able to get the 2016g data from the sources mentioned in earlier emails, in tar.gz, tar.lz, .zip or uncompressed form. Please see: http://mm.icann.org/pipermail/tz/2016-September/024162.html For what it's worth, Debian did that and is using 2016g now: https://packages.debian.org/sid/tzdata
On Sep 26, 2016, at 12:26 PM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
On 09/26/2016 09:02 AM, Deborah Goldsmith wrote:
Is there any news on this? Any further word from ICANN?
Although the IESG has been pinged about the situation with https://www.iana.org/time-zones, I'm afraid I know of no news yet.In the meantime you should be able to get the 2016g data from the sources mentioned in earlier emails, in tar.gz, tar.lz, .zip or uncompressed form. Please see:
This is quite insane. The whole point of getting IANA involved in this process is to put it in the hands of a well established reliable organization. If they aren't capable of dealing with this trivial clerical work promptly, we need to take it away from them and put the job into hands that are capable of doing the job. I really don't like the notion of having to go to alternate data sources when the official one is not doing its job. It's hard to set up sane processes for using data when part of the process is "go look around for a believable copy of the latest data". paul
I agree completely. Debbie
On Sep 26, 2016, at 10:25 AM, Paul.Koning@dell.com wrote:
On Sep 26, 2016, at 12:26 PM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
On 09/26/2016 09:02 AM, Deborah Goldsmith wrote:
Is there any news on this? Any further word from ICANN?
Although the IESG has been pinged about the situation with https://www.iana.org/time-zones, I'm afraid I know of no news yet.In the meantime you should be able to get the 2016g data from the sources mentioned in earlier emails, in tar.gz, tar.lz, .zip or uncompressed form. Please see:
This is quite insane. The whole point of getting IANA involved in this process is to put it in the hands of a well established reliable organization.
If they aren't capable of dealing with this trivial clerical work promptly, we need to take it away from them and put the job into hands that are capable of doing the job.
I really don't like the notion of having to go to alternate data sources when the official one is not doing its job. It's hard to set up sane processes for using data when part of the process is "go look around for a believable copy of the latest data".
paul
On 9/26/2016 10:25 AM, Paul.Koning@dell.com wrote:
If they aren't capable of dealing with this trivial clerical work promptly, we need to take it away from them and put the job into hands that are capable of doing the job.
I am not directly dependent on tz, but I can't help to observe it worked very well before IANA was somehow involved. I wish we had kept our trust with what had proven to work.
I really don't like the notion of having to go to alternate data sources when the official one is not doing its job.
This is trivial to solve. Just call what Paul does "official" and be done with it. The whole thing hangs together because he is here, not because IANA is involved. What value did they add? Thanks Paul for all your work (and ado before that, and all the contributors), and sorry we imposed IANA on you. Eric.
Hi Eric, Hi all, On 9/27/16, > If they aren't capable of dealing with this trivial clerical work promptly, we need to take it away from them and put the job into hands that are capable of doing the job. I am not directly dependent on tz, but I can't help to observe it worked very well before IANA was somehow involved. I wish we had kept our trust with what had proven to work. … Thanks Paul for all your work (and ado before that, and all the contributors), and sorry we imposed IANA on you. I am genuinely interested to know, beyond this isolated issue, what problems or issues you would like us to see addressed with how the time zone repository is managed. We want to be responsive to your needs, but can only address issues if they are shared with us. This specific issue is now resolved and solely centred on unexpected format changes to the repository (partly the lzip release bundle, but we also came across another issue with the Makefile that we’ve been diagnosing with Paul). Based on this experience, in the future we look forward to getting potential format changes shared with us in advance so we can have time to prepare before the next edition is ready for publication. If there are systemic issues that affect you we will address them. So please, let me know. kim
Paul, could you educate us all on what the publishing process with ICANN involves? Should it not be detailed in RFC6557 or some other document? Thanks, Matt ________________________________ From: tz-bounces@iana.org <tz-bounces@iana.org> on behalf of Paul Eggert <eggert@cs.ucla.edu> Sent: Monday, September 26, 2016 9:26 AM To: Deborah Goldsmith Cc: Time zone mailing list; Susan Abraham Subject: Re: [tz] tzdata 2016g On 09/26/2016 09:02 AM, Deborah Goldsmith wrote:
Is there any news on this? Any further word from ICANN?
Although the IESG has been pinged about the situation with https://www.iana.org/time-zones, I'm afraid I know of no news yet.In the IANA - Time Zone Database<https://www.iana.org/time-zones> www.iana.org Time Zone Database. The Time Zone Database (often called tz or zoneinfo) contains code and data that represent the history of local time for many representative ... meantime you should be able to get the 2016g data from the sources mentioned in earlier emails, in tar.gz, tar.lz, .zip or uncompressed form. Please see: http://mm.icann.org/pipermail/tz/2016-September/024162.html For what it's worth, Debian did that and is using 2016g now: https://packages.debian.org/sid/tzdata Debian -- Details of package tzdata in sid<https://packages.debian.org/sid/tzdata> packages.debian.org time zone and daylight-saving time data. This package contains data required for the implementation of standard local time for many representative locations around ...
On 09/26/2016 10:58 AM, Matt Johnson wrote:
Paul, could you educate us all on what the publishing process with ICANN involves?
ICANN has a private Git-based repository that stores distribution tarballs and metadata. When I cut a new release I send them a copy of it, and they turn a crank that installs it into their private repository and then publishes the result on their web site. Although ICANN granted me access to their private system so that I could update the repository and push a button to turn the crank, the access was via Juniper VPN and was so flaky and awkward for me that I eventually gave up using it and we fell back on the current approach. We've long known that the process should be improved. The current problems are likely to light a fire under that and actually get it done, though not instantly I'm afraid. As part of its improvement the process should be documented better than it is now.
On Sep 26, 2016, at 4:09 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 09/26/2016 10:58 AM, Matt Johnson wrote:
Paul, could you educate us all on what the publishing process with ICANN involves?
ICANN has a private Git-based repository that stores distribution tarballs and metadata. When I cut a new release I send them a copy of it, and they turn a crank that installs it into their private repository and then publishes the result on their web site. Although ICANN granted me access to their private system so that I could update the repository and push a button to turn the crank, the access was via Juniper VPN and was so flaky and awkward for me that I eventually gave up using it and we fell back on the current approach.
If that's all there is, then their whole task amounts to a few hundred lines of Python or some other scripting language, and the time required to publish a release should be measured in seconds. There's nothing in what you described that appears to need any human intervention at all, let alone human intervention by humans who take weeks to do their job. paul
Hi folks, This thread has just been brought to my attention. Apologies this update hasn’t been posted sooner, if this was a regular update we’d plan to have it posted within a day. The changes to the packaging of this update necessitate some technical changes at our end, as our propagation mechanism assumes the historical structure of the updates. Paul told me at the time the update wasn’t urgent, and in the midst of getting ready for the IANA stewardship transition expected to occur later this week, we’ve had a lot on our plate. I’ll be working on getting this out the door ASAP. kim On 9/26/16, 9:02 AM, "tz-bounces@iana.org on behalf of Deborah Goldsmith" <tz-bounces@iana.org on behalf of goldsmit@apple.com> wrote: Hi, Is there any news on this? Any further word from ICANN? Thanks, Debbie Sent from my iPad > On Sep 21, 2016, at 12:37 AM, Paul Eggert <eggert@cs.ucla.edu> wrote: > > Sowmya Gangishetty wrote: >> Why is 2016g tzdata not published on IANA website? > > That's been discussed on the mailing list, e.g.: > > http://mm.icann.org/pipermail/tz/2016-September/024135.html
On Sep 27, 2016, at 1:57 PM, Kim Davies <kim.davies@icann.org> wrote:
Hi folks,
This thread has just been brought to my attention. Apologies this update hasn’t been posted sooner, if this was a regular update we’d plan to have it posted within a day.
Where timezones are concerned, there is NO such thing as a "regular update". Updates happen whenever some government decides to change the rules, which is an utterly unpredictable event. The process needs to be able to post releases within a day or so without depending on any non-existent schedules. paul
Hi Kim, Just to be sure, IANA will continue to post the older formats (.tar.gz) as well as the new format (.tar.lz), correct? Thanks, Debbie
On Sep 27, 2016, at 10:57 AM, Kim Davies <kim.davies@icann.org> wrote:
Hi folks,
This thread has just been brought to my attention. Apologies this update hasn’t been posted sooner, if this was a regular update we’d plan to have it posted within a day.
The changes to the packaging of this update necessitate some technical changes at our end, as our propagation mechanism assumes the historical structure of the updates. Paul told me at the time the update wasn’t urgent, and in the midst of getting ready for the IANA stewardship transition expected to occur later this week, we’ve had a lot on our plate.
I’ll be working on getting this out the door ASAP.
kim
On 9/26/16, 9:02 AM, "tz-bounces@iana.org on behalf of Deborah Goldsmith" <tz-bounces@iana.org on behalf of goldsmit@apple.com> wrote:
Hi,
Is there any news on this? Any further word from ICANN?
Thanks, Debbie
Sent from my iPad
On Sep 21, 2016, at 12:37 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
Sowmya Gangishetty wrote:
Why is 2016g tzdata not published on IANA website?
That's been discussed on the mailing list, e.g.:
On 2016-09-27 11:57, Kim Davies wrote:
This thread has just been brought to my attention. Apologies this update hasn’t been posted sooner, if this was a regular update we’d plan to have it posted within a day. The changes to the packaging of this update necessitate some technical changes at our end, as our propagation mechanism assumes the historical structure of the updates. Paul told me at the time the update wasn’t urgent, and in the midst of getting ready for the IANA stewardship transition expected to occur later this week, we’ve had a lot on our plate. I’ll be working on getting this out the door ASAP.
Sounds like the addition of the .tar.lz package during the PTI changes was enough to derail the process. Even seemingly minor changes to prod ops can involve a lot of work to allow the changes to be applied to production systems: sometimes the major effort is getting approvers to believe that the potential impact to existing operations is essentially zero, when something new and discrete is being added. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
On 09/27/2016 04:38 PM, Brian Inglis wrote:
Sounds like the addition of the .tar.lz package during the PTI changes was enough to derail the process.
I already suggested privately to them that they release 2016g in traditional form only, if the .tar.lz file is what is causing the delay. I think the main problem here, though, is that I originally told them that the matter was not urgent, and this caused it to become swamped by other matters relating to their forthcoming reorganization.
On Sep 27, 5:25pm, eggert@cs.ucla.edu (Paul Eggert) wrote: -- Subject: Re: [tz] tzdata 2016g | On 09/27/2016 04:38 PM, Brian Inglis wrote: | > Sounds like the addition of the .tar.lz package during the PTI changes | > was enough to derail the process. | | I already suggested privately to them that they release 2016g in | traditional form only, if the .tar.lz file is what is causing the delay. | I think the main problem here, though, is that I originally told them | that the matter was not urgent, and this caused it to become swamped by | other matters relating to their forthcoming reorganization. I think this whole compression format discussion is silly. We've spent more time discussing it than any savings in space or time. Just put out both formats (gz and lz) and be done with it. christos
participants (9)
-
Brian Inglis -
christos＠zoulas.com -
Deborah Goldsmith -
Eric Muller -
Kim Davies -
Matt Johnson -
Paul Eggert -
Paul.Koning＠dell.com -
Sowmya Gangishetty