[tz] tzdata2012f available

Robert Elz kre at munnari.OZ.AU
Fri Sep 14 15:52:24 UTC 2012

    Date:        Fri, 14 Sep 2012 10:52:06 -0400
    From:        Bennett Todd <bet at rahul.net>
    Message-ID:  <CAA9gXs-zrwxRYBsav4QRVppFwHgZg-3ZpNqqr0964goeRgSDZg at 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).


More information about the tz mailing list