[tz] Uruguay out of DST
guy at alum.mit.edu
Sat Jul 11 22:51:30 UTC 2015
On Jul 11, 2015, at 2:53 PM, John Hawkinson <jhawk at MIT.EDU> wrote:
> 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?
No, I don't - that's why I didn't respond.
I just don't want to let the vendors completely off the hook here. There are a number of things they could do to improve the handling of the tzdb. Apple's done a lot more than most vendors (they have the only UN*X time-zone-selection GUI that doesn't just throw the tz ids, or slightly prettified versions of the tz ids, at the user, and they have a version of localtime() etc. that doesn't assume that you can load up the tzdb entry at program startup time and never worry about it afterwards), but it'd be nice if they could do more (although, as noted below, the localtime() etc. implementation isn't *quite* as good as it could be, unless I've missed something).
> 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.
If it's not *that* around the corner, perhaps it might be worthwhile for vendors to consider a mechanism for updating time zone data that doesn't require a full-blown OS update, especially given that time zone/DST updates often occur on schedules that don't line up very well with OS update schedules.
>>> 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),
Why do you not think it is? "Here's a bunch of files; replace the current versions of these files, and deliver whatever indications are necessary to get currently running software to update whatever it has to update in response to that". The latter of the two is the only part that's different from updating printer drivers (and, if those drivers are loaded into currently-running software, even *that* might not be different, as that software might have to be told to unload and reload the existing driver code/printer description file/etc.).
Currently, OS X's localtime() code wouldn't recognize the tzdb update when it gets a "com.apple.system.timezone" notify(3) notification, so the indication would be a "do a reboot" indication; were it not only to lstat() /etc/timezone and check whether it changed, but stat() it to find out whether what it points to changed, even *that* wouldn't be necessary - just deliver a "com.apple.system.timezone" notification and notifications for the file or files that changed. (The lstat() is currently only done if a "system time zone changed" notification has been delivered; the same would be true of the stat(), so it's not as if it'd add frequent file system operations.)
> the politics are different,
Are different, or might be different?
> and politics in large enterprise companies are not trivially
> 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,
Actually, I'd say that there might not be a "printer mechanism" at all.
Given that Apple updates printer drivers, digital camera RAW image software, Web browsers, etc. outside of the normal "here's a new dot release of the OS" mechanism, I suspect there's an underlying more general update mechanism currently used for several purposes.
And given that many Linux distributions don't have a "here's a new dot release of the OS" mechanism, they have a general "update these components" mechanism, there's *definitely* a more general update mechanism there.
So the cost there might just be the cost of packaging a tzdb update in the mechanism in question. I would not be surprised to hear that the Linux distributions in question *already* do that, so that changes to the update software on the update servers, the update client, and the process for doing tzdb updates aren't necessary. There would probably be some cost for Apple doing it, but I'm not convinced that it would necessarily be enough to prevent it from being done - it might not require Tim Cook's approval.
Perhaps there *are* OSes where there's no mechanism for updating individual components out of band, some of whose users might have to do the tzdb update themselves if the government of a country whose time zones they need to deal with decides, on very short notice, to change the way time is kept in that country.
> 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.
So why are people from OS suppliers complaining here about updates not being provided by the tzdb maintainers in a sufficiently timely fashion, if the users don't push back if the time zone information isn't up-to-date?
> We could also talk about how printer drivers are really an issue for
> "early adopters,"
Early adopters of a particular printer model? I bought the printer we have back in the late 1990's, and I think I got driver updates for it at least a few years ago, perhaps sooner.
More information about the tz