[tz] Uruguay out of DST

Deborah Goldsmith goldsmit at apple.com
Sun Jul 12 02:00:50 UTC 2015


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

We don’t live in an optimal world.

1. Governments make changes to their time zone rules with short notice and inadequate information.
2. IANA needs to collect the new information and update the tz database. That takes time.
3. Different vendors have different processes, and some take longer than others.

We can’t do much about the first one. As I’ve already mentioned the relevant people at Apple are well aware that sooner is better when it comes to updates. I’m pretty sure our friends at Google are well aware of that too. Comparing the release processes of something like Android or iOS to those of Ubuntu is not helpful. They’re different products with different models.

Perhaps in the future Google or Apple will be able to turn around time zone updates more quickly. We don’t live in that world yet.

And none of that means that IANA shouldn’t strive to release updated tz data as soon as possible (but no sooner). Let’s all work on making our own parts better and faster.

Deborah

> On Jul 11, 2015, at 5:49 PM, Paul Eggert <eggert at CS.UCLA.EDU> wrote:
> 
> 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.



More information about the tz mailing list