[tz] Uruguay out of DST

[John Hawkinson]

I note, Guy, that you didn't respond to my comments about what the
tz distribution can do. Even if you can get a few major vendors to
solve this, you're unlikely to get many to do it quickly. So getting
tz's own house in order (i.e. more predictable; better clarity on 
release engineering; etc.) is worth doing. Do you disagree?

Guy Harris <guy at alum.mit.edu> wrote on Sat, 11 Jul 2015
at 14:00:25 -0700 in <BEE38224-A7BB-45B6-9FCE-6CC8C4A6A93A at alum.mit.edu>:

> Or to avoid having to bundle tzdb updates with a full-blown OS release.
> As such, it's not compelling at this juncture (with tzdist around
> > the corner?)
> 
> How "around the corner" is it?

I do not know.

> > to ask vendors to do that -- even if it were possible, which I think
> > it really isn't.
> 
> Why do you think tzdb updates are different from printer driver updates?

Not to be cynical, but the biggest reason is that the vendors in question
have a current mechanism for executing printer updates in a timely fashion
and they do not have that for tzdata updates. Even if the technical
mechanism could be the same (and I don't think it is), the politics are
different, and politics in large enterprise companies are not trivially
navigable.

You can argue that such a system should be built, but then a plausible
response is that that engineering effort should be spent on tzdist.

You might say that extending the printer mechanism to cover timezones
should be ~0 work, but that seems unlikely to be something that the
folks holding the pursestrings would believe, even if it were true.


In another analysis, customers who spend money on a printer that
doesn't work get upset, and they complain to both their OS vendor and
their printer vendor (who is concerned about revenue), which leads to
revenue-based incentives (indirect and direct) to get it right.

On the other hand, users do not have to spend money for timezones,
and thus they are disconnected from the financials. And users with
wrong timezones for their country solve the problem some other way and
move on -- change the zone or change the clock.


We could also talk about how printer drivers are really an issue for
"early adopters," but there is no analagous category for timezones
(time travelers?).



Anyhow, I don't disagree that "it would be great" if vendors adopted
a more rapid mechanism to deploy timezone updates. Or that they
implemented tzdist faster. Or implemented an interim measure
prior to tzdist. I just don't think it is easy.

And even if it is easy and the vendors are wrong about it being hard,
convincing them of this is not very likely.


The tz project should do what it can do to solve this problem, even as
vendors work to do so as well. And tz can do that by having more
predictable release timings, and making it easier to use the
development tree.

--jhawk at mit.edu
  John Hawkinson