[tz] Uruguay out of DST

[Paul Eggert]

On 07/11/2015 01:40 PM, John Hawkinson wrote:
> 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."

It's both, of course.  There's no fiction here.

The experimental github repository could be moved to another hosting 
site tomorrow, without affecting the official releases.  In this sense 
it has the same role that the old SCCS repository did.  The main 
difference is that the github repository is world-readable whereas the 
old SCCS repository was private.
>  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.)

In the current experimental repository a monotonic identifier is the 
commit timestamp in UTC.

> 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, ..."

Many releases are special cases, and I doubt whether tzdata 
redistributors could rely on such a specific formula in practice. The 
best we could say would be something along the lines of "we'll try to 
publish a new release a week before the change takes effect, but we 
can't promise this because sometimes governments give us even less 
notice than that".

If redistributors can't broadcast changes to their users within a few 
days, their users will lose out on occasion.  This would be true even if 
the tz project generated new releases with zero delay, so there's 
nothing the tz project can do to "fix" this.  What needs to be fixed is 
the processes some redistributors use to propagate tz updates to their 
users' machines.  Three months is far too long a delay.  Updates clearly 
can be done reasonably quickly, within a matter of days not months, as 
shown by the redistributors like Ubuntu who are doing so.

Yes, Apple and Google have far more users than Ubuntu but they can scale 
to those users.  Yes, they have to deal with ICU but so do Ubuntu and 
the other guys.  Yes, Google must communicate to its own downstream 
redistributors, but this problem can be addressed (see Debian and 
Ubuntu). None of these problems are fundamental obstacles to getting 
changes out far more quickly than what happens now, and this quickness 
is needed regardless of what the tz project does.