
The 2012f release of the tz data is available. (The code hasn't changed since the last release, except for the version number.) This release reflects the following change circulated on the tz mailing list: * australasia (Pacific/Fiji): Fiji DST is October 21 through January 20 this year. (Thanks to Steffen Thorsen.) Here are links to the release files: http://www.iana.org/time-zones/repository/releases/tzdatacodef.tar.gz http://www.iana.org/time-zones/repository/releases/tzdata2012f.tar.gz ftp://ftp.iana.org/tz/releases/tzcode2012f.tar.gz ftp://ftp.iana.org/tz/releases/tzdata2012f.tar.gz As usual, links to the latest release files are here: http://www.iana.org/time-zones/repository/tzcode-latest.tar.gz http://www.iana.org/time-zones/repository/tzdata-latest.tar.gz ftp://ftp.iana.org/tz/tzcode-latest.tar.gz ftp://ftp.iana.org/tz/tzdata-latest.tar.gz This release corresponds to commit 66f0c30ddc300f824e993977777cb68ad6207ca1 in the unofficial github repository at <https://github.com/eggert/tz>. Here is the GPG checksum for the release files: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAABAgAGBQJQUYUUAAoJEO2X6Q5iqn40lhYP/2exm3EO2jbIgFmnrIE0r0ap n/y4ZdyoqF5+MZ63Q+XnpR5kHSJRss/OkH5o65qBjwEpUzSwK1yCLMse9flkoPND gP/ZxpajHH/G/zqDiP8mtCpiVxTnneBrixnduYsSAqFntsYUWq9vdgTOrRXE0zpo +PFcbSr8KZwMH7/SUvly8EIIaJDcGsHDaw4YxdEMyhqlJKOgfaZSBWNVXfATOYFZ +BF+Z1qLGGF9Yv6PI17Wttm7Ywh1UH/ESvyxuCxvsP9ibyVWdb1ruP5xmUZcETkd EyU47Pa1wVLnPqI6d0f5NnxA6WunFkTH5qAaflS+6/X9yEb+Xs3gfNl0hmacxbi3 OImJVGD3LSv6e74505Jpd5K4CG8TO2dtp68z66ku3B+A1pS4Nxc9BbrkxiehgdPj wJOuHzIpyC3Mv2DKsvX0wY8jwaIykMd8jWf7c7Buw4WVbHAYxG2EsEQJ3GUkwkDT 4ulwDgLVk2Ejs8/JBBB30qZDj04RrhRhWgxDdCbUAdiK1tAYDyoYG1Tdg3S+7PWf xGAdnkRQ/GhtllhiSFzp4IahDFGLK2W8AOjZOQ06xyOLBwdY9VEldFAgFvBmMgJi 7XOsvoJKerMSBzpU88kMUnsSoP17sqz/eZQ1bEEEAXkNneOhCUfrxMyq4MSlxEgS fx0h067lXx7LXlfzRNTq =wylp -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAABAgAGBQJQUX/LAAoJEO2X6Q5iqn40j5gP/jFCjU382StQRTjCXMSyDFPw fTIgvA9vrrDil1MzLuoI1qhr/tfhC9Jv9c2BBdClQWPxpXEDlTQhjIKTWzkcm3TE BOVUEb55D4Ak9rkGZYQ0NkjOChOB4ukbKiSvfVp2/PuqqbEds+WQpGtq5R+oWrrV sr2LT8Ut4EeF/Vie9k7pjSjpq3I2vBVFti+BCxS/LXbD1OfcLA9Em6hibAckdN0q zhhyMkxnidIpmP4aBYEobJZcoUcX1USjv2inoSSNDZK2cPQRJOhQ1k7NFHnfXc3V deBENRLoJbNZeq1Tf7VAXzW5lTYK+ENekY6olMbnP8RwX6PGI03ulj9Di4eY6F4g k6cp0bIVcJy8wnNIWudA5LF0RjF3HXMd9IvlRETYUd8vaRn9SZ/x/kiNSr8wXFvF Xvk2SQWSBXAWlceK3V1deGmxRStu5o+MDhaC1Y8EhEaWTzcU7lnUC0RruBwYjkuv MMjuxFL1vDVjoezRynm8Ju0QRJ7O72J+zGo2fQzUcfU9TrcDL7CRhkXXiQ/LzwKB L9CxJx5BKcX7XLcMk2/8WJNoit8pkwV1LhPcDVuaRf5bHzMw+5nHKXLVwmttM0Rg lstsbXwLDH6a8ooiiTQAv4OVdMlPFAe+L5gZahy1OAidMMXLkSSx71u6IrGsj+ah bWfNB7JX9R0/xbdwYRzd =FC3e -----END PGP SIGNATURE-----

On Thu, Sep 13, 2012 at 12:08 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
The 2012f release of the tz data is available. (The code hasn't changed since the last release, except for the version number.) This release reflects the following change circulated on the tz mailing list:
* australasia (Pacific/Fiji): Fiji DST is October 21 through January 20 this year. (Thanks to Steffen Thorsen.)
Here are links to the release files:
http://www.iana.org/time-zones/repository/releases/tzdatacodef.tar.gz http://www.iana.org/time-zones/repository/releases/tzdata2012f.tar.gz
The URL containing tzdatacodef.tar.gz is 404; I think you might have meant tzcode2012f.tar.gz http://www.iana.org/time-zones/repository/releases/tzcode2012f.tar.gz<http://www.iana.org/time-zones/repository/releases/tzdatacodef.tar.gz> which does exist.
ftp://ftp.iana.org/tz/releases/tzcode2012f.tar.gz ftp://ftp.iana.org/tz/releases/tzdata2012f.tar.gz
As usual, links to the latest release files are here:
http://www.iana.org/time-zones/repository/tzcode-latest.tar.gz http://www.iana.org/time-zones/repository/tzdata-latest.tar.gz
ftp://ftp.iana.org/tz/tzcode-latest.tar.gz ftp://ftp.iana.org/tz/tzdata-latest.tar.gz
This release corresponds to commit 66f0c30ddc300f824e993977777cb68ad6207ca1 in the unofficial github repository at <https://github.com/eggert/tz>.
-- 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 09/13/2012 12:08 AM, Paul Eggert wrote:
Here are links to the release files:
http://www.iana.org/time-zones/repository/releases/tzdatacodef.tar.gz http://www.iana.org/time-zones/repository/releases/tzdata2012f.tar.gz
ftp://ftp.iana.org/tz/releases/tzcode2012f.tar.gz ftp://ftp.iana.org/tz/releases/tzdata2012f.tar.gz
As Jonathan Leffler noted, there's a typo in that first URL; it should have been http://www.iana.org/time-zones/repository/releases/tzcode2012f.tar.gz Sorry about the confusion.

On 2012-09-13 15:52, Paul Eggert wrote:
On 09/13/2012 12:08 AM, Paul Eggert wrote:
Here are links to the release files:
http://www.iana.org/time-zones/repository/releases/tzdatacodef.tar.gz http://www.iana.org/time-zones/repository/releases/tzdata2012f.tar.gz
ftp://ftp.iana.org/tz/releases/tzcode2012f.tar.gz ftp://ftp.iana.org/tz/releases/tzdata2012f.tar.gz
As Jonathan Leffler noted, there's a typo in that first URL; it should have been
http://www.iana.org/time-zones/repository/releases/tzcode2012f.tar.gz
Sorry about the confusion.
Will tzcode be released every time tzdata is released even though the only change is to the (shared) version number (and vice versa)? -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-

On 09/14/2012 01:41 AM, Ian Abbott wrote:
Will tzcode be released every time tzdata is released even though the only change is to the (shared) version number (and vice versa)?
That's the way things are currently set up, yes. It is a bit of an annoyance, and perhaps we can think of a better way to do it. One possibility would be to put the Makefile (which has the version number) into both distributions.

I can't see a reason for a shared version number. Sending out a "new" package that is actually just the old package with a new number attached is confusing at best. It's more helpful for the version number to say when the package in question has changed. So how about two packages, with two separate version numbers? If you want to avoid confusion from similar-looking version strings that don't mean the same thing, you could use names like tzdata2012f for tzdata, and tzcode2012-2 for tzcode. That way no one can think that a given tzcode "goes with" a given tzdata. paul On Sep 14, 2012, at 10:35 AM, Paul Eggert wrote:
On 09/14/2012 01:41 AM, Ian Abbott wrote:
Will tzcode be released every time tzdata is released even though the only change is to the (shared) version number (and vice versa)?
That's the way things are currently set up, yes. It is a bit of an annoyance, and perhaps we can think of a better way to do it. One possibility would be to put the Makefile (which has the version number) into both distributions.

On 09/14/2012 07:48 AM, Paul_Koning@Dell.com wrote:
I can't see a reason for a shared version number.
The version number has to be stored somewhere. Currently, it's stored in the Makefile. The Makefile is part of the tzcode distribution, not the tzdata distribution. So if a new release of the tzdata distribution is cut, the tzcode distribution needs to be updated as well. It's just a minor glitch, easily fixed when someone gets around to it.

I believe a question is the possibility of a change in the zone data requiring an update to zic. If that's right, perhaps the release cutting procedure could test that older versions of zic work on the new data, and produce binary zoneinfo files differing only in the changed rules. Crudely, if zic runs without error and zdump produces changes that are explained by the change notes, then tzcode doesn't have to be updated.

Date: Fri, 14 Sep 2012 10:52:06 -0400 From: Bennett Todd <bet@rahul.net> Message-ID: <CAA9gXs-zrwxRYBsav4QRVppFwHgZg-3ZpNqqr0964goeRgSDZg@mail.gmail.com> | I believe a question is the possibility of a change in the zone data | requiring an update to zic. If that's right, perhaps the release cutting | procedure could test that older versions of zic work ... No, for the issue at hand, it is nothing like that complex. if any of the source (code) files have been updated, a new tzcode distribution is needed, if any of the data files have been updated, a new tzdata distribution is needed. For deciding when to make new releases it is that simple. The version in Makefile thing is also simple - just remove it again. It never was there before, and aside from (perhaps) being used to make the tgz filenames, can't be being used for anything (the distribution filenames could come from somewhere else). The version was added mostly because people wanted a way to know what version they had, without keeping the tgz file around - perviously the tgz filename was the only place the version was identified. It doesn't need to be in the Makefile for that, we could just have README_CODE and README_DATA files (one in each distribution) that give the version (and perhaps a few other lines of useful info). Those files could even be built (when needed) from a master file (not distributed perhaps) that contains the current version identifier (which would be used to make whichever, or both, of the code & data files is needed, and then incremented). There are of course a zillion other ways that this could be handled, including (if the iana site access Paul has permits it) just not bothering to update whichever of the distribution files hasn't changed (after doing everything else that builds both of them - just remove the one that isn't needed and keep the old distribution). Or we could completely change the distribition format and make the whole question moot - these days there's probably no longer much reason for actually keeping the code & data distributions separate, we could just have one single distribution, or we could have one complete distribution, and perhaps a data only version that is always updated when the main file is updated for those people who want data only (wanting source only is so rare it can be ignored). And I'm sure there are plenty of other ways that we could "fix" this problem - but I don't thing fixing it is urgent. We're going to need tzdata2012g very soon now, as that Western Samoa transition is in just over 2 weeks ... the people there said my patch "didn't work" but didn't tell me in what way, or what problem they had (yet anyway), I'm awaiting a reply - but it is Saturday there already... (If anyone else detected a problem, please let me know - if you usually test these things, and didn't yet, please do). When that's ready if we also end up with a tzcode2012g that's a null change from tzcode2012f (and 2012e) that's not really a problem - just as long as the release info says (as it did this time) that there are no changes, so we can just ignore it (I ignore tzcode changes - aside from putting the distribution file on munnari's tz archive - most times anyway, since the most frequent changes are to the html files (etc), and I have no direct use for any of those, I only bother processing tzcode updates when the C code has changed - and that's not very common. The release notes are how I find out what I need to do). kre

On 2012-09-14 15:35, Paul Eggert wrote:
On 09/14/2012 01:41 AM, Ian Abbott wrote:
Will tzcode be released every time tzdata is released even though the only change is to the (shared) version number (and vice versa)?
That's the way things are currently set up, yes. It is a bit of an annoyance, and perhaps we can think of a better way to do it. One possibility would be to put the Makefile (which has the version number) into both distributions.
I was thinking more on the lines of allowing the Makefile to build both the tzcode and tzdata packages, but conditionally uploading one or both as "official" releases based on what's changed since the previous official release of each (an "executive decision"). -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Tel: +44 (0)161 477 1898 FAX: +44 (0)161 718 3587 )=-

On 09/14/2012 09:50 AM, Ian Abbott wrote:
I was thinking more on the lines of allowing the Makefile to build both the tzcode and tzdata packages, but conditionally uploading one or both as "official" releases based on what's changed since the previous official release of each (an "executive decision").
Yes, that would also work. In fact, it's what I did at first, but just as I was about to announce the release I noticed that the released files didn't *exactly* match what was in the unofficial repository, due to the updated version number in the Makefile. I like things to match, so I released the code tarball too. In hindsight perhaps I was being too nitpicky here, as this issue has wasted people's time. Robert suggested auxiliary version-number files, which would work, though they'd add two more files to the distribution. Another possibility would be to keep the code version number in the Makefile, as now, and to put the data version number into one of the files of the data tarball, in a comment in zone.tab say. A downside of both of these approaches, though, is that the two version numbers would be in different places, making it more likely that I'll forget to update one or the other. So perhaps it'd be better just to do as you suggest.

Date: Fri, 14 Sep 2012 10:09:41 -0700 From: Paul Eggert <eggert@cs.ucla.edu> Message-ID: <505364D5.2050208@cs.ucla.edu> | A downside of both of these | approaches, though, is that the two version numbers would be | in different places, making it more likely that I'll forget | to update one or the other. No, you don't want to do it that way, you want a single file in the repository that is the version number, and then the Makefile target that creates the distribution files incorporates that version number in whatever places in the eventual distribution it is decided that it should live (Makefile, zone.tab, README.xxx or even in every file if desired) just before making the tar file. That is, the distributed tgz is made out of (slightly) modified copies of (some of) the files from the repository, not those files directly. The only place in the repository that the version number is ever seen is in that one single file, and that one file I would not include in either the data or source distritions (it isn't needed to build or use the code or data, only to make distributions, and only the owner of the repository needs to be able to do that). You don't want to include it in just one tgz file, as then whever that file happens to be an older version than the other, this new file looks to have incorrect contents, and you don't want to include it in both, as that leads to races on extraction (which version you get depends which of the tgz's is extracted last). The strategy of just not uploading the code tgz when it hasn't changed means that the eventual distributed pair of files (files with different versionids in their names) would end up with an incorrect version number (as it is now in the Makefile) for the data (worse than not having one at all). And of course, people who only download the data (relying upon their system's integrated code version) don't get a version number at all (except the one in the tgz filename). kre

On 09/14/2012 04:15 PM, Robert Elz wrote:
That is, the distributed tgz is made out of (slightly) modified copies of (some of) the files from the repository, not those files directly.
That "slightly" and "some of" are bothersome. It's nicer if we can distribute all files as-is. The distributed files should have all the info needed to make the distribution, so that the whole procedure is self-documenting and automatic.
You don't want to include it in just one tgz file
Yes, and that's the advantage of putting the data version number into (say) zone.tab. This would avoid races on extraction and the other problems that you mentioned. So perhaps we should do it that way, even if it's a bit more error-prone because the two version numbers are in different files.

Date: Fri, 14 Sep 2012 16:33:03 -0700 From: Paul Eggert <eggert@cs.ucla.edu> Message-ID: <5053BEAF.2010607@cs.ucla.edu> | That "slightly" and "some of" are bothersome. The "some of" shouldn't be, that was just meant to indicate that we (or you) get to decide which files get the version number in them, which might be some of the files, or all of them, a choice we make - after that it's irrelevant to this issue. The "slightly modified" part sounds not so good, but in reality, it is what we're doing now anyway, and what just about everyone does ... the real master files are the ones in the git repository (or when ado was doing it, his sccs repository, or for the short while I did it, RCS) and those we don't distribute - to truly distribute unmodified master files, allowing everyone to do everything, we'd need to distribute via "git clone" or whatever git has to make repository copies (I'm not a git user, if that isn't obvious). We could do that, but for 99% of the users it is useless overhead and unnecessary extra work to deal with. Given that we're modifying the files anyway, does it really matter whether or not the distribution contains exactly the same bits as whatever git's equivalent of the sccs/rcs "checkout" commands produce? That is, we do a checkout, then one small extra post-processing step, and the results of that are the distribution. | The distributed files should | have all the info needed to make the distribution, so that the | whole procedure is self-documenting and automatic. Self documenting and automatic, absolutely. All the info, just almost, and just because there's no safe way to make that actually happen the way we have historically done the distributions (as the master copy has a single version number that applies to everything, but everyone else gets two potentially different versions, one for the code, and one for the data). If we abolished the code/data distinction, then we could distribute everything. Otherwise we distribute everything, except one 5 byte (well, 6 including the \n) file that contains "2012f" (or whatever version we're up to). | Yes, and that's the advantage of putting the data version number | into (say) zone.tab. Where it goes isn't as important as that it is in some file distributed in tzdataNNNNx.tgz and not distribued in tzcodeNNNNx.tgz (and vice versa for the code version number). It could be in any single file that qualifies in each (like Makefile and zone.tab) or it could be in every file. This should really be based upon what is best for the users, as it makes almost no difference to anything else. | So perhaps we should do it that way, even if it's a bit more | error-prone because the two version numbers are in different files. Please don't jumble the decisions on what the results should look like, with how they should be constructed - while those are related, they don't have to be even close to the same. It is trivially easy to avoid the "bit more error-prone" by making sure that there is exactly one version number to manage, and then using automation to apply that version number to the distribution files in the proper way. Given that it is so easy, I think we should do that -- but as this affects operations that only you ever perform, it really comes down to what works best for you (as long as the end result looks OK, none of the rest of us will care much how much work you need to do to get it to that state...) I haven't just written the few lines of shell script (that would be implemented as Makefile recipe lines) and sent them, as it isn't clear to me that the simpler solution of just abandoning the split code & data distributions, and going back to a single tgz file, with a single trivial version number (the way it was originally,) isn't also the better solution. There's almost no-one concerned with 1200bps uucp data transfers any more... kre

Robert Elz <kre@munnari.OZ.AU> writes:
I haven't just written the few lines of shell script (that would be implemented as Makefile recipe lines) and sent them, as it isn't clear to me that the simpler solution of just abandoning the split code & data distributions, and going back to a single tgz file, with a single trivial version number (the way it was originally,) isn't also the better solution.
That would also make it possible to create the tarball with a simple git archive call. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
participants (7)
-
Andreas Schwab
-
Bennett Todd
-
Ian Abbott
-
Jonathan Leffler
-
Paul Eggert
-
Paul_Koning@Dell.com
-
Robert Elz