[tz] Uruguay out of DST

[John Hawkinson]

I think Deb Goldsmith is right and the tz db needs to change its
release dynamics, which could happen in a few ways. But it could also
improve the documentation of the release dynamics.

I think we should hope that tzdist can get deployed before major
vendors find a "magic bullet" to speed up their OS releases. As such,
it's not compelling at this juncture (with tzdist around the corner?)
to ask vendors to do that -- even if it were possible, which I think
it really isn't.

Paul Eggert <eggert at cs.ucla.edu> wrote on Fri, 10 Jul 2015
at 00:05:57 -0700 in <559F6ED5.6040701 at cs.ucla.edu>:

> If these delays cause problems for you, it's reasonable to use the
> unofficial repository at <https://github.com/eggert/tz> as a basis
> for operating system patches.  That is, users of the tz database
> have a choice of either a bleeding edge unofficial version that is
> more up-to-date but is also more likely to contain errors, or a
> more-stable official version that may not have the very latest
> experimental changes but should work well for those who keep
> reasonably up-to-date with the official version.

This seems to me to be somewhat of a fiction, and to me an unhealthy
one.

It is not the "unofficial repository."
It is the "development repository from which releases are made."

We (those of us on this list) should probably all be reviewing commits
to the repo in realtime and vendors should be encouraged to pull
releases from it; at least if there are no other significant changes
to release dynamics.

To facilitate this, it would help if there was a monotonic identifier
that increased for each commit in-between releases
(VERSION=2015e+20150701a perhaps, corresponding to
9ebb8da281487886d4110388eb139578c72d1176, the first commit on July 1
(UTC)). I don't know if that is something reasonable to require of
Paul. (And, unfortunately, I don't think there's a good git mechanism
for it.)


But really I think the complaint is one of consistency and
reliability.  If a vendor could reliably say, "I can expect a tzdata
release to follow within 14 days after a change to a rule that takes
effect 14-90 days out, within 30 days after a change to a rule that
takes effect 90-180 days out, ..." then the vendor can decide in an
informed fashion whether to wait for 2015f or just use
2015e+20150701a.

Today, it's very hard for a vendor to predict whether they should
wait an unbounded time for a release or should move forward outside
the release process.

Could the rules be made a little more clear (constraining the
maintainer's flexibility, unfortunately)?

--jhawk at mit.edu
  John Hawkinson