A history maintaining repository for tzdata
I note that some others have created some repositories for tzdata, but I'd really like to see the history of what Paul and Arthur have done be maintained. Commits that have useful commit messages and "correct" dates. To that end I've created the following repository (I stuck it on two hosters as I saw there were concerns about github on the list): https://github.com/lyda/tzdata https://gitorious.org/tzdata The README file explains how the import was done and what might need to be fixed: https://github.com/lyda/tzdata/blob/master/README https://gitorious.org/tzdata/tzdata/blobs/master/README If people want me to recreate it differently I'm happy to do so. It takes about a minute to build from scratch. The git repo is only 1.5M BTW so if someone wants to setup private hosting it really won't take up much room or bandwidth. If people like this I'm happy to do the same for tzcode. Kevin PS It would amuse me if the tz project had one of the oldest git commits on github/gitorious/wherever: https://github.com/lyda/tzdata/commit/dcf9a59f640d3e24745b36a9b5593add336a01... -- Kevin Lyda Dublin, Ireland US Citizen overseas? We can vote. Register now: http://www.votefromabroad.org/
Hi, Le vendredi 07 octobre 2011 à 21:27 +0100, Kevin Lyda a écrit :
I note that some others have created some repositories for tzdata, but I'd really like to see the history of what Paul and Arthur have done be maintained. Commits that have useful commit messages and "correct" dates.
Nice work, better than mine. Using the release mail is obviously the best way to partially reconstruct the history and give some meaning to each commit. But it is still not perfect: at best, the sccs / rcs information should be imported to a DVCS. BTW, setting up a repository now would only be useful for the interim maintainers, so that, when Arthur came back to normal business, he can replay the changes on its own versionning system.
To that end I've created the following repository (I stuck it on two hosters as I saw there were concerns about github on the list):
Why host the tzdata on a US based service, are you looking for trouble ? Regards. -- Yann Droneaud
On 10/08/11 01:06, Yann Droneaud wrote:
Why host the tzdata on a US based service, are you looking for trouble ?
Distributed version control systems are highly resilient against loss. In the normal mode of operation, everyone who checks out the repository gets a full copy of the history. If the master is lost for whatever reason, the community can designate any sufficiently recent copy as the new master. BTW, there are tools for synchronizing changes between mercurial and git -- the maintainer can (for instance) use git as the master, but they, or anyone else so motivated, can clone it into hg, and both copies have the full change history. And the reverse is also possible (master in hg, slave in git). Also, I'd hope that any repo that gets set up starts with something at least as old as the ancestral post to mod.sources in (I think) 1986. - Bill
Bill Sommerfeld wrote:
Distributed version control systems are highly resilient against loss. In the normal mode of operation, everyone who checks out the repository gets a full copy of the history. If the master is lost for whatever reason, the community can designate any sufficiently recent copy as the new master.
BTW, there are tools for synchronizing changes between mercurial and git -- the maintainer can (for instance) use git as the master, but they, or anyone else so motivated, can clone it into hg, and both copies have the full change history. And the reverse is also possible (master in hg, slave in git).
Personally I run Hg locally simply because it works transparently on both Linux and Windows, something that git simply does not support ( tools are EITHER linux or windows ). But I don't have any problem simply cloning from a git repository and posting changes back ... it all just works transparently from Hg. Working the other way however is something of a pig as using hg from git support is simply not as good as hg using git ... -- 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// Firebird - http://www.firebirdsql.org/index.php
On Sat, Oct 8, 2011 at 10:16, Bill Sommerfeld <sommerfeld@alum.mit.edu>wrote:
On 10/08/11 01:06, Yann Droneaud wrote:
https://github.com/lyda/tzdata
Why host the tzdata on a US based service, are you looking for trouble ?
Distributed version control systems are highly resilient against loss. [...]
Also, I'd hope that any repo that gets set up starts with something at least as old as the ancestral post to mod.sources in (I think) 1986.
I don't know if it is any help, but I have a modest (but by no means complete) collection of the TZ code and data tar files dating back to 2002 (nowhere near 1986, but better than nothing). -rw-r--r-- 1 jleffler staff 170045 Feb 20 2006 tz32code2006b.tar.bz2 -rw-r--r-- 1 jleffler staff 172888 Feb 20 2006 tz64code2006b.tar.bz2 -rw-r--r-- 1 jleffler staff 14623658 Sep 26 2007 tzarchive.bz2 -rw-r--r-- 1 jleffler staff 90157 Apr 2 2002 tzcode2002b.tar.bz2 -rw-r--r-- 1 jleffler staff 98974 Dec 15 2003 tzcode2003e.tar.bz2 -rw-r--r-- 1 jleffler staff 168682 Jul 11 2005 tzcode2005j.tar.bz2 -rw-r--r-- 1 jleffler staff 168487 Jul 14 2005 tzcode2005k.tar.bz2 -rw-r--r-- 1 jleffler staff 169051 Nov 21 2005 tzcode2005n.tar.bz2 -rw-r--r-- 1 jleffler staff 168815 Dec 27 2005 tzcode2005r.tar.bz2 -rw-r--r-- 1 jleffler staff 174663 Aug 28 2006 tzcode2006k.tar.bz2 -rw-r--r-- 1 jleffler staff 174406 Oct 10 2006 tzcode2006n.tar.bz2 -rw-r--r-- 1 jleffler staff 175056 Jan 8 2007 tzcode2007a.tar.bz2 -rw-r--r-- 1 jleffler staff 177552 May 7 2007 tzcode2007f.tar.bz2 -rw-r--r-- 1 jleffler staff 177708 Aug 20 2007 tzcode2007g.tar.bz2 -rw-r--r-- 1 jleffler staff 177869 Oct 1 2007 tzcode2007h.tar.bz2 -rw-r--r-- 1 jleffler staff 177614 Dec 3 2007 tzcode2007j.tar.bz2 -rw-r--r-- 1 jleffler staff 177510 Dec 31 2007 tzcode2007k.tar.bz2 -rw-r--r-- 1 jleffler staff 176860 Sep 2 2008 tzcode2008e.tar.bz2 -rw-r--r-- 1 jleffler staff 176763 Oct 6 2008 tzcode2008g.tar.bz2 -rw-r--r-- 1 jleffler staff 176736 Oct 13 2008 tzcode2008h.tar.bz2 -rw-r--r-- 1 jleffler staff 177120 Jan 21 2009 tzcode2009a.tar.bz2 -rw-r--r-- 1 jleffler staff 177392 Feb 9 2009 tzcode2009b.tar.bz2 -rw-r--r-- 1 jleffler staff 177278 Apr 6 2009 tzcode2009e.tar.bz2 -rw-r--r-- 1 jleffler staff 177629 May 26 2009 tzcode2009h.tar.bz2 -rw-r--r-- 1 jleffler staff 177678 Jul 20 2009 tzcode2009k.tar.bz2 -rw-r--r-- 1 jleffler staff 178139 Nov 2 2009 tzcode2009q.tar.bz2 -rw-r--r-- 1 jleffler staff 178299 Nov 9 2009 tzcode2009r.tar.bz2 -rw-r--r-- 1 jleffler staff 178685 Mar 22 2010 tzcode2010f.tar.bz2 -rw-r--r-- 1 jleffler staff 178951 Aug 23 2010 tzcode2010l.tar.bz2 -rw-r--r-- 1 jleffler staff 179237 Oct 13 2010 tzcode2010m.tar.bz2 -rw-r--r-- 1 jleffler staff 179282 Oct 31 2010 tzcode2010n.tar.bz2 -rw-r--r-- 1 jleffler staff 180035 Jan 24 2011 tzcode2011a.tar.bz2 -rw-r--r-- 1 jleffler staff 180012 Feb 7 2011 tzcode2011b.tar.bz2 -rw-r--r-- 1 jleffler staff 180349 Mar 14 2011 tzcode2011d.tar.bz2 -rw-r--r-- 1 jleffler staff 180720 Apr 25 06:59 tzcode2011g.tar.bz2 -rw-r--r-- 1 jleffler staff 116957 Aug 29 15:50 tzcode2011i.tar.bz2 -rw-r--r-- 1 jleffler staff 101228 Apr 2 2002 tzdata2002b.tar.bz2 -rw-r--r-- 1 jleffler staff 107596 Dec 15 2003 tzdata2003e.tar.bz2 -rw-r--r-- 1 jleffler staff 112375 Jul 11 2005 tzdata2005j.tar.bz2 -rw-r--r-- 1 jleffler staff 111731 Jul 14 2005 tzdata2005k.tar.bz2 -rw-r--r-- 1 jleffler staff 114733 Nov 21 2005 tzdata2005n.tar.bz2 -rw-r--r-- 1 jleffler staff 115573 Dec 27 2005 tzdata2005r.tar.bz2 -rw-r--r-- 1 jleffler staff 116408 Feb 20 2006 tzdata2006b.tar.bz2 -rw-r--r-- 1 jleffler staff 121974 Sep 18 2006 tzdata2006l.tar.bz2 -rw-r--r-- 1 jleffler staff 122027 Oct 10 2006 tzdata2006n.tar.bz2 -rw-r--r-- 1 jleffler staff 122336 Jan 8 2007 tzdata2007a.tar.bz2 -rw-r--r-- 1 jleffler staff 124409 May 7 2007 tzdata2007f.tar.bz2 -rw-r--r-- 1 jleffler staff 124469 Aug 20 2007 tzdata2007g.tar.bz2 -rw-r--r-- 1 jleffler staff 125501 Oct 1 2007 tzdata2007h.tar.bz2 -rw-r--r-- 1 jleffler staff 126189 Nov 1 2007 tzdata2007i.tar.bz2 -rw-r--r-- 1 jleffler staff 126476 Dec 3 2007 tzdata2007j.tar.bz2 -rw-r--r-- 1 jleffler staff 126763 Dec 31 2007 tzdata2007k.tar.bz2 -rw-r--r-- 1 jleffler staff 132331 Sep 2 2008 tzdata2008e.tar.bz2 -rw-r--r-- 1 jleffler staff 133674 Sep 15 2008 tzdata2008f.tar.bz2 -rw-r--r-- 1 jleffler staff 134233 Oct 6 2008 tzdata2008g.tar.bz2 -rw-r--r-- 1 jleffler staff 134603 Oct 13 2008 tzdata2008h.tar.bz2 -rw-r--r-- 1 jleffler staff 134433 Oct 27 2008 tzdata2008i.tar.bz2 -rw-r--r-- 1 jleffler staff 135562 Jan 21 2009 tzdata2009a.tar.bz2 -rw-r--r-- 1 jleffler staff 134913 Feb 9 2009 tzdata2009b.tar.bz2 -rw-r--r-- 1 jleffler staff 137125 Apr 13 2009 tzdata2009f.tar.bz2 -rw-r--r-- 1 jleffler staff 138070 May 26 2009 tzdata2009h.tar.bz2 -rw-r--r-- 1 jleffler staff 138886 Jul 20 2009 tzdata2009k.tar.bz2 -rw-r--r-- 1 jleffler staff 142267 Nov 2 2009 tzdata2009q.tar.bz2 -rw-r--r-- 1 jleffler staff 142687 Nov 16 2009 tzdata2009s.tar.bz2 -rw-r--r-- 1 jleffler staff 145487 Jan 25 2010 tzdata2010b.tar.bz2 -rw-r--r-- 1 jleffler staff 145833 Mar 8 2010 tzdata2010d.tar.bz2 -rw-r--r-- 1 jleffler staff 145161 Mar 8 2010 tzdata2010e.tar.bz2 -rw-r--r-- 1 jleffler staff 145728 Mar 22 2010 tzdata2010f.tar.bz2 -rw-r--r-- 1 jleffler staff 146749 Apr 19 2010 tzdata2010i.tar.bz2 -rw-r--r-- 1 jleffler staff 148478 Aug 23 2010 tzdata2010l.tar.bz2 -rw-r--r-- 1 jleffler staff 148460 Oct 13 2010 tzdata2010m.tar.bz2 -rw-r--r-- 1 jleffler staff 148734 Oct 31 2010 tzdata2010n.tar.bz2 -rw-r--r-- 1 jleffler staff 149353 Jan 24 2011 tzdata2011a.tar.bz2 -rw-r--r-- 1 jleffler staff 149679 Feb 7 2011 tzdata2011b.tar.bz2 -rw-r--r-- 1 jleffler staff 150899 Mar 14 2011 tzdata2011d.tar.bz2 -rw-r--r-- 1 jleffler staff 151574 Apr 1 2011 tzdata2011e.tar.bz2 -rw-r--r-- 1 jleffler staff 151848 Apr 25 06:59 tzdata2011g.tar.bz2 -rw-r--r-- 1 jleffler staff 152348 Jun 27 04:49 tzdata2011h.tar.bz2 -rw-r--r-- 1 jleffler staff 154011 Aug 29 15:50 tzdata2011i.tar.bz2 -rw-r--r-- 1 jleffler staff 154939 Sep 12 07:59 tzdata2011j.tar.bz2 -rw-r--r-- 1 jleffler staff 154943 Sep 26 12:55 tzdata2011k.tar.bz2 Obviously, they were distributed as gzipped tar files; I simply gunzip them and then bzip2 compress them (and should really switch to xz, but haven't bothered to do so yet). -- Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h> Guardian of DBD::Informix - v2011.0612 - http://dbi.perl.org "Blessed are we who can laugh at ourselves, for we shall never cease to be amused."
On Sat, Oct 8, 2011 at 22:46, Jonathan Leffler <jonathan.leffler@gmail.com> wrote:
I don't know if it is any help, but I have a modest (but by no means complete) collection of the TZ code and data tar files dating back to 2002 (nowhere near 1986, but better than nothing).
Thanks, but I have all these. I've also got most if not all the releases between 1986 and 1993 on mod.sources/comp.sources.unix. The first release I have was on Fri Mar 7 17:43:08 -0500 1986 by elsie!ado. It's from here: http://groups.google.com/group/mod.sources/msg/f72eb180696d86d3?dmode=source... I'm not sure if there were previous changes. These are the SCCS keywords from the files in the shar: asia: # @(#)asia 2.1 australasia: # @(#)australasia 2.1 etcetera: # @(#)etcetera 2.1 europe: # @(#)europe 2.1 Makefile: # @(#)Makefile 2.1 mkdir.c: static char sccsid[] = "@(#)mkdir.c 7.2"; northamerica: # @(#)northamerica 2.1 pacificnew: # @(#)pacificnew 2.1 README: @(#)README 2.1 scheck.c: static char sccsid[] = "@(#)scheck.c 7.9"; settz.3: .. @(#)settz.3 2.1 settz.c: static char sccsid[] = "@(#)settz.c 2.1"; strchr.c: static char sccsid[] = "@(#)strchr.c 7.3"; tzcomp.8: .. @(#)tzcomp.8 2.1 tzcomp.c: static char sccsid[] = "@(#)tzcomp.c 2.1"; tzdump.c: static char sccsid[] = "@(#)tzdump.c 2.1"; tzfile.5: .. @(#)tzfile.5 2.1 tzfile.h: /* @(#)tzfile.h 2.1 */ years.sh: : '@(#)years.sh 2.1' SCCS revision identifiers (SIDs) are of the form release.revision[.branch.sequence]. We can ignore the SIDs for strchr.c, scheck.c and mkdir.c since those came with the system (BSD?). But the others imply there was an earlier release. Perhaps ado worked in private for a period and then did an sccs get -r2 -e and an sccs delta on all files just before release? BTW, it appears that this will work best with the data and the source in one repo as that's how the releases were originally done. Kevin -- Kevin Lyda Dublin, Ireland US Citizen overseas? We can vote. Register now: http://www.votefromabroad.org/
Kevin Lyda wrote:
BTW, it appears that this will work best with the data and the source in one repo as that's how the releases were originally done.
Moving forward, separate repo's make a lot more sense? The code is still version 'g' this year, while the data has moved on. No need to have to 'release' new code copies with every data update. Of cause if the releases are dropped altogether, and only the repo is supported, then a single point makes sense, but personally I'd prefer to see 'packaged' data releases since git is not the best of bases for DVCS and hopefully a much more generic base will develop ... getting git on a windows machine still needs to be made a bit more reliable! -- 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// Firebird - http://www.firebirdsql.org/index.php
On 09/10/2011, at 20:03 , Lester Caine wrote:
Kevin Lyda wrote:
BTW, it appears that this will work best with the data and the source in one repo as that's how the releases were originally done.
Moving forward, separate repo's make a lot more sense? The code is still version 'g' this year, while the data has moved on. No need to have to 'release' new code copies with every data update.
Of cause if the releases are dropped altogether, and only the repo is supported, then a single point makes sense, but personally I'd prefer to see 'packaged' data releases since git is not the best of bases for DVCS and hopefully a much more generic base will develop ... getting git on a windows machine still needs to be made a bit more reliable!
As somebody who manages the zoneinfo data for the FreeBSD project, yes packaged data releases are much easier to track than checking the git repo manually, then not knowing which version of the imported data is currently used on the system and how it related to the git "revision" numbers. Edwin
On Sun, Oct 9, 2011 at 10:49, Edwin Groothuis <edwin@mavetju.org> wrote:
As somebody who manages the zoneinfo data for the FreeBSD project, yes packaged data releases are much easier to track than checking the git repo manually, then not knowing which version of the imported data is currently used on the system and how it related to the git "revision" numbers.
Absolutely. For end-users the tarballs have to continue to exist and be released. As for git revision numbers I label every commit with a tag. For the tzcode/tzdata commits I use the tarball name; for the mod.sources/comp.sources.unix releases I use the id assigned by the newsgroup (except for the first(?) which didn't have one). Kevin -- Kevin Lyda Dublin, Ireland US Citizen overseas? We can vote. Register now: http://www.votefromabroad.org/
On Sun, Oct 9, 2011 at 10:03, Lester Caine <lester@lsces.co.uk> wrote:
Kevin Lyda wrote:
BTW, it appears that this will work best with the data and the source in one repo as that's how the releases were originally done.
I really can't decide on this one. It really looks like ado keeps the whole thing in one directory and has maintenance scripts that generate the tarballs. What I'm leaning towards is starting with them all in one dir and then, withe the initial 1993 release moving to having them in tzcode and tzdata. It might make the migration of the sccs history a bit harder, but I think it will better reflect what is happening.
Moving forward, separate repo's make a lot more sense? The code is still version 'g' this year, while the data has moved on. No need to have to 'release' new code copies with every data update.
There will be a separate commit for each tzdata and each tzcode release.
Of cause if the releases are dropped altogether, and only the repo is supported, then a single point makes sense, but personally I'd prefer to see
Absolutely not - it would be insane to get rid of tarballs (or some package format - the initial releases were shar and patch so it's changed over time). I just want the history of the project maintained. First because I like history but also because having the complete history in one easy to view place might be of assistance to ado and eggert (that's why I've made sure to reference sources in each commit message). Part of that history is the tarballs (and shars and patches) themselves. So they should definitely be maintained. And obviously they're very useful for end-users for future releases. This is just for "digital historians" (or whatever such a field will be called) and a possible base for future maintainers of the code/data.
'packaged' data releases since git is not the best of bases for DVCS and hopefully a much more generic base will develop ... getting git on a windows machine still needs to be made a bit more reliable!
I have never really used Windows so I was unaware of this issue. I actually started using DVCS with hg, but trends really seem to be favouring git over hg and bzr from what I've been reading. I don't want to start a VCS war though so I can look at providing both a git and hg repo (I think the migration from git to hg is pretty simple). I could put both up onto bitbucket.org - they now support both formats. And a Windows version would likely be very useful for legal assistance reasons - I suspect lawyers and judges might not be Unix users... I'll offer this suggestion however. I do all my work on an OS X box. While OS X has unix roots its fs is not case sensitive. At times that's an issue. So to avoid that I generally use VirtualBox and some handy Linux distro (lately Debian or Ubuntu since my employer uses those) to do actual work on unix-related projects. Machines are fast enough these days that it's as fast as I need it to be. Kevin -- Kevin Lyda Dublin, Ireland US Citizen overseas? We can vote. Register now: http://www.votefromabroad.org/
Kevin Lyda wrote:
I have never really used Windows so I was unaware of this issue. I actually started using DVCS with hg, but trends really seem to be favouring git over hg and bzr from what I've been reading. I don't want to start a VCS war though so I can look at providing both a git and hg repo (I think the migration from git to hg is pretty simple). I could put both up onto bitbucket.org - they now support both formats. And a Windows version would likely be very useful for legal assistance reasons - I suspect lawyers and judges might not be Unix users...
Kevin ... At the present time, there is no need to add a separate hg 'master'. I'm having to live with 'git' but it's a no-brainer since hg happily imports and works with git repo's just as if they were hg anyway. Today it's just easier to pander to the git camp by having a git 'master' but looking at the next generation of DVCS coming along, there may well be an alternate migration later. git is geared to compiled source code as is hg, but extending things to manage bug reporting, document control such as user manuals and even releases is an area where an alternate base may be a better starting point. I can see a point in the future when all the hand merging that you are having to do will be done automatically even from the original source control methods :) As for 'releases', as you say, both git and hg get extending with scripts that replace the 'compile' step with a suitable 'build' cycle creating a distribution pack rather than a compiled program. -- 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// Firebird - http://www.firebirdsql.org/index.php
Gentlemen: Could we please drop the discussion of the minutia of version control systems, please? In the first part, this is a bikeshed -- many have opinions and they mostly do not matter, any color would do. Secondly, it's really a question of the discretion of the maintainer. Let us as assume that is kre, and let him deal with it as he wishes. It doesn't really have much effect on the data. Several of you have published repositories and collections, and that is great. They'll work well for people. But I know many of us depend on this list (and its predecessor) for useful communication about timezine information, and from that perspective its signal-to-noise ratio has worsened dramatically. So, can we please try to drastically reduce the volume of traffic here that pertains to the details of version control options, and just like kre do as he wishes? Thank you. --jhawk@mit.edu John Hawkinson +1 617 797 0250 p.s.: As I noted on apps-discuss, RECAP is now working properly, (a bug handling an archive.org error condition was fixed by Dhruv Kapadia), and all of http://www.archive.org/download/gov.uscourts.mad.139342/gov.uscourts.mad.139... http://archive.recapthelaw.org/mad/139342/ http://www.archive.org/details/gov.uscourts.mad.139342/ should work now. I like the first one, but others might prefer the other presentations. I also said there, "I will commit to keeping it up to date within a day, and probably more like within the hour, of any court filings." I'll also make sure this list is aware of filings in the case, at least as long as doing so doesn't seem to generate an annoying level of traffic.
Lester Caine wrote:
Moving forward, separate repo's make a lot more sense?
No. They're developed together, and interoperate by being in the same directory. They should be in a single repo, in the same directory. The code/data split only appears when packaging them for distribution. -zefram
Zefram wrote:
Moving forward, separate repo's make a lot more sense? No. They're developed together, and interoperate by being in the same directory. They should be in a single repo, in the same directory. The code/data split only appears when packaging them for distribution.
Still a grey area ;) Two submodules in the one database makes sense, keeping the version numbers of the two halves manageable. Depends on the DVCS configuration if a submodule can be cloned on it's own. -- 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// Firebird - http://www.firebirdsql.org/index.php
Date: Mon, 10 Oct 2011 11:46:47 +0100 From: Lester Caine <lester@lsces.co.uk> Message-ID: <4E92CD17.80307@lsces.co.uk> | Zefram wrote: | > No. They're developed together, and interoperate by being in the same | > directory. | Still a grey area ;) Note that they're kind of difficult to separate, as yearistype.sh is distributed with the data (which it is, and is referenced by the data files), but it is built and installed with the rest of the code (which it also is ...) kre
Robert Elz wrote:
Note that they're kind of difficult to separate,
On a historical note, I've discovered the origin of this split. It's a suggestion from Robert Elz, archived at <http://mm.icann.org/pipermail/tz/1992-November/000227.html>: "perhaps separate the rules from the code in the ftp archives, the rules change more frequently ...". In fact, since then there have been about 85% as many code releases as data releases (~160 code and ~190 data), so that part of the rationale hasn't fared so well. The other part of the rationale is about users with their own code, of which there are some, but the occasional necessary feature added to zic poses difficulties for this mode of use. -zefram
On 10/11/2011 10:40 AM, Zefram wrote:
Robert Elz wrote:
Note that they're kind of difficult to separate,
On a historical note, I've discovered the origin of this split. It's a suggestion from Robert Elz, archived at <http://mm.icann.org/pipermail/tz/1992-November/000227.html>: "perhaps separate the rules from the code in the ftp archives, the rules change more frequently ...". In fact, since then there have been about 85% as many code releases as data releases (~160 code and ~190 data), so that part of the rationale hasn't fared so well. The other part of the rationale is about users with their own code, of which there are some, but the occasional necessary feature added to zic poses difficulties for this mode of use.
-zefram
For what it's worth, I'm one of the "users with their own code." I released a tzdata reader for Tcl on 2004-08-18. I think I've needed to touch it only 3-4 times in the seven years since then as a result of tzdata changes (and all but one of those was arguably a bug in the original code that just wasn't tickled by the earlier tzdata files). The format is actually quite stable. The frequent code releases are more about changes internal to the C library, rather than to zic. -- 73 de ke9tv/2, Kevin
On Oct 11, 2011, at 7:40 AM, Zefram wrote:
The other part of the rationale is about users with their own code, of which there are some, but the occasional necessary feature added to zic poses difficulties for this mode of use.
Is that "users with their own code to parse time zone source files" or "users with their own code to read compiled binary time zone files"? I think there have been only a couple of changes to the binary file format, and I suspect most of the "own code" is reading the compiled files.
On 11 October 2011 18:49, Guy Harris <guy@alum.mit.edu> wrote:
On Oct 11, 2011, at 7:40 AM, Zefram wrote:
The other part of the rationale is about users with their own code, of which there are some, but the occasional necessary feature added to zic poses difficulties for this mode of use.
Is that "users with their own code to parse time zone source files" or "users with their own code to read compiled binary time zone files"? I think there have been only a couple of changes to the binary file format, and I suspect most of the "own code" is reading the compiled files.
The Java parsers (Joda-Time, JSR-310 and probably the JDK itself) all read the source files, not the binaries. Thats because the source files contain a lot more information. Stephen
On Sat, Oct 8, 2011 at 09:06, Yann Droneaud <yann@droneaud.fr> wrote:
But it is still not perfect: at best, the sccs / rcs information should be imported to a DVCS.
Looking at the keywords in the files, ado still uses SCCS and has since the beginning. Amusingly I work with the maintainer of CSSC so I should be able to pester him for issues that arise. Plus he might appreciate a case study for a DVCS conversion project - he's pretty adamant that CSSC is a conversion tool! Kevin -- Kevin Lyda Dublin, Ireland US Citizen overseas? We can vote. Register now: http://www.votefromabroad.org/
I've updated the tz-history-scripts to include kre's most recent release and to generate either git or hg repositories. These can obviously be useful to the current (or future) maintainer, but from reading patches on the list it's clear that others have used things like git or RCS (for example, kre and eggert) even while ado was using SCCS. So these scripts (or more likely, the example repos) could be useful to future contributors. The scripts are here: https://github.com/lyda/tz-history-scripts Example repositories are here: Git version: https://github.com/lyda/tz Hg version: https://bitbucket.org/lyda/tz A note on the example repositories, don't send pull requests to them. And I wouldn't suggest using github or bitbucket's forking feature. First, I'm not the maintainer. If kre wants to make his own repo and publish that, he'll let folks know. Secondly, when I get new data I will at times blow them away and recreate them. If you clone from them (and please do, it's what they are there for), update your .git/config or your .hg/hgrc to remove mention of where you cloned them from to avoid issues when I do reset them. They're there as an example and as a convenience for people who don't want to use the scripts and download all the data. And it's an understandable thing to avoid: The total size of all the tarballs is: 46M The mercurial repo is: 3.2M The git repo is: 3.0M Clearly a DVCS is better at compressing files than tar and gzip! :) Kevin
participants (12)
-
Bill Sommerfeld -
Edwin Groothuis -
Guy Harris -
John Hawkinson -
Jonathan Leffler -
Kevin Kenny -
Kevin Lyda -
Lester Caine -
Robert Elz -
Stephen Colebourne -
Yann Droneaud -
Zefram