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@alum.mit.edu> wrote on Sat, 11 Jul 2015 at 14:00:25 -0700 in <BEE38224-A7BB-45B6-9FCE-6CC8C4A6A93A@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@mit.edu John Hawkinson