unofficial tz repository on github
I've set up an unofficial repository containing the tz code and data at <https://github.com/eggert/tz>. This is supposed to contain the history of changes to the tz code and data, back to the first commit in 1984. I plan to use it to publish further proposed changes. The official tz distributions will remain in their current location, at <ftp://ftp.iana.org/tz/>. The tz code was formerly maintained as an SCCS repository, but nowadays Git seems more appropriate. Unfortunately no publicly-available SCCS-to-Git converter was up to the task of migrating the tz repository; the two I tried mishandled old time stamps and lost revisions! So I wrote my own. This task languished until Arthur David Olson's recent higher-priority message about Morocco <http://mm.icann.org/pipermail/tz/2012-July/018123.html>, which prompted me to move this task to the top of my list. The unofficial repository currently contains the latest public tz code and data distributions (tzcode2012b and tzdata2012c), with the following further modifications, each of which represents a proposed change: * Switch from SCCS to git. https://github.com/eggert/tz/commit/dccd5a16af62c52f2b49a2fe56270a710617cbbd This alters how version numbers are handled. * Morocco does not observe DST from Jul 20 03:00 to Aug 20 02:00. https://github.com/eggert/tz/commit/0e0bb39b15fbbaa759d66951ec727d640d17acc5 These are Arthur's changes for Morocco, with minor editing. * Adjust to iana.org distribution method. https://github.com/eggert/tz/commit/943c565e512880520c685c3233fa127f2341d3a3 This documents the switch to iana.org as a distribution site. * Fix HTML validation issues. https://github.com/eggert/tz/commit/8a52da39ed9a4988da930ded4946b0b24cc45f2c This is so that "make check" works again. I'll send details about these proposed changes in followup emails. Each email will contain one of the patches, along with a brief log entry describing its purpose. This is the style used by "git format-patch". Unfortunately I have not had time to look at the other changes that are pending. This will require looking through emails since about March, and merging the changes into the database. My impression is that these changes are less pressing, though, and I thought I'd get the Morocco change out first, and to make sure that this new distribution scheme works. Comments are welcome, especially those that fix bugs in the Morocco change or the development machinery.
On Thu, Jul 19, 2012 at 9:10 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
I've set up an unofficial repository containing the tz code and data at <https://github.com/eggert/tz>. This is supposed to contain the history of changes to the tz code and data, back to the first commit in 1984. I plan to use it to publish further proposed changes. The official tz distributions will remain in their current location, at <ftp://ftp.iana.org/tz/>.
Just to clarify: I understand the github repository is unofficial as a means of distribution, but it's considered to be the canonical repository, right? There's no intention to setup a more-official repository on some other hosting service? I think this is a great step to making the timezone maintenance a little more transparent. Cheers, Dirkjan
On 07/19/2012 01:00 AM, Dirkjan Ochtman wrote:
There's no intention to setup a more-official repository on some other hosting service?
I don't intend to set up a competing public repository, no. The IANA's repository is private and there are no plans to change this. The IANA's public distribution will continue to be the "canonical" one.
On Thu, Jul 19, 2012 at 10:07 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
I don't intend to set up a competing public repository, no. The IANA's repository is private and there are no plans to change this. The IANA's public distribution will continue to be the "canonical" one.
But the IANA repository is git, too? Can you elaborate on why it's private? Cheers, Dirkjan
On Jul 19, 2012, at 1:11 AM, Dirkjan Ochtman <dirkjan@ochtman.nl> wrote:
On Thu, Jul 19, 2012 at 10:07 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
I don't intend to set up a competing public repository, no. The IANA's repository is private and there are no plans to change this. The IANA's public distribution will continue to be the "canonical" one.
But the IANA repository is git, too? Can you elaborate on why it's private?
The short answer is, the RFC didn't call for it, and in our discussions when we were transferring the repository to ICANN the idea never came up, so we haven't implemented it. The more useful answer is Paul recently raised the idea of a public git repository privately. I am certainly interested in the idea, but as there is not currently a public IANA git service, it is not something we have readily available. To launch a non-experimental production service to do this would mean identifying the exact requirements, obtaining agreement, setting it up, testing, and rolling it out. I imagine a bare minimum approach (i.e. publishing it as a read-only repository via HTTP) is probably relatively straightforward, but it could get more complex if there are other requirements. kim
"KD" == Kim Davies <kim.davies@icann.org> writes:
KD> To launch a non-experimental production service to do this would KD> mean identifying the exact requirements, obtaining agreement, KD> setting it up, testing, and rolling it out. I imagine a bare minimum KD> approach (i.e. publishing it as a read-only repository via HTTP) is KD> probably relatively straightforward, but it could get more complex KD> if there are other requirements. Or icann could just open an account at github or gitorious or ... and publish it there. Putting it at https://github.com/icann/tz or https://gitorious.org/icann/tz would be fine. -JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
On Thu, Jul 19, 2012 at 8:39 PM, Kim Davies <kim.davies@icann.org> wrote:
The short answer is, the RFC didn't call for it, and in our discussions when we were transferring the repository to ICANN the idea never came up, so we haven't implemented it.
The more useful answer is Paul recently raised the idea of a public git repository privately. I am certainly interested in the idea, but as there is not currently a public IANA git service, it is not something we have readily available. To launch a non-experimental production service to do this would mean identifying the exact requirements, obtaining agreement, setting it up, testing, and rolling it out. I imagine a bare minimum approach (i.e. publishing it as a read-only repository via HTTP) is probably relatively straightforward, but it could get more complex if there are other requirements.
That makes sense, thank you. Cheers, Dirkjan
On 07/19/2012 01:11 AM, Dirkjan Ochtman wrote:
But the IANA repository is git, too? Can you elaborate on why it's private?
The IANA repository is Git-based, yes. It contains a bit more information than what's in the unofficial public repository, related to how stuff gets distributed and published from IANA. It also contains less information, as it focuses on what gets published, and does not record every individual change ever made to the database. I am not as familiar with the internal details of the IANA repository, and haven't investigated the possibilities of publishing it. For one thing we'd need to clarify the copyright status of the stuff that's in it but not in the unofficial public repository. Eventually I hope that the functions of the two repositories can merge, so that one is just a branch or a subset of the other, or something like that. This will take some doing, though. I'm using Github for the unofficial repository because IANA is not currently set up to do public Git hosting. This may change, though that would also take some work, as there are nontrivial security and scalability issues.
Paul Eggert <eggert@cs.ucla.edu> writes:
I've set up an unofficial repository containing the tz code and data at <https://github.com/eggert/tz>. This is supposed to contain the history of changes to the tz code and data, back to the first commit in 1984. I plan to use it to publish further proposed changes. The official tz distributions will remain in their current location, at <ftp://ftp.iana.org/tz/>.
This is much appreciated, thank you. PM
Paul Eggert <eggert@cs.ucla.edu> wrote: |I've set up an unofficial repository containing the tz code and |data at <https://github.com/eggert/tz>. This is supposed to |contain the history of changes to the tz code and data, back to |the first commit in 1984. I plan to use it to publish further |proposed changes. The official tz distributions will remain in |their current location, at <ftp://ftp.iana.org/tz/>. Thanks. This will make automatic updates possible. |The tz code was formerly maintained as an SCCS repository, but |nowadays Git seems more appropriate. Unfortunately no But here i disagree. SCCS is a POSIX tool that works pretty good, especially if you do TZ=UTC before you use it. And especially for such a small project like this one, with only one (or two) committers. With nice uuencoded binary data :). I like SCCS. |publicly-available SCCS-to-Git converter was up to the task of |migrating the tz repository; the two I tried mishandled old time |stamps and lost revisions! So I wrote my own. This task languished Jörg Schilling includes a pretty good RCS->SCCS converter in his SCCS distribution, if you use it in exactly the way he had in mind. (I do use the older SUN/Heirloom one, only half the size and pretty much self-containing, though. *Much* easier to compile.) I think going the other way should be a little bit easier due to the POSIX standard -i and -l options to get(1)? [.] | * Switch from SCCS to git. | https://github.com/eggert/tz/commit/dccd5a16af62c52f2b49a2fe56270a710617cbbd | This alters how version numbers are handled. No more ?0%0[steffen@sherwood site]$ what /usr/share/zoneinfo/zone.tab /usr/share/zoneinfo/zone.tab zone.tab 8.43 |Comments are welcome[.] What a pity. Cold comfort for change. --steffen
On 07/19/2012 03:50 AM, Steffen Daode Nurpmeso wrote:
SCCS is a POSIX tool that works pretty good,
It's a fine tool, but to be honest I was an RCS guy back in the day, and anyway version-control systems have moved on. These days I typically use a distributed version control system and I'd rather not be limited to the local data model of SCCS or RCS, as that model makes it too much of a hassle to maintain stuff from the various computers that I use daily. There are many plausible DVCS systems out there, but git is a reasonable choice in that space, partly because I use it daily in other projects.
participants (6)
-
Dirkjan Ochtman -
James Cloos -
Kim Davies -
Paul Eggert -
Petr Machata -
Steffen Daode Nurpmeso