[tz] Uruguay out of DST

[Deborah Goldsmith]

> Presumably ICU can, at least, reload whatever form of tzdata it uses when the system time zone changes (I didn't have to reboot my Mac when I flew from California to Pennsylvania a few years ago, and a lot of the GUI-based software I was using was presumably using ICU), so there is - at least in OS X's and presumably iOS's version of ICU - presumably at least *some* of the mechanism in place to allow it to update the information for the current time zone without having to restart the process.
> 
> So why would updating ICU’s time zone data not be doable with the same mechanism that could be used for UN*X's time zone data?

Because they’re not the same thing.

Capsule version: ICU has a data file. ICU is not currently architected to allow you to swap out the data file, or a portion of it, while a process using ICU is running.

Selecting a different time zone from the existing data file is an entirely different matter from replacing some or all of the data file itself.

Further information can be found at icu-project.org.

Deborah

> On Jul 11, 2015, at 5:47 PM, Guy Harris <guy at alum.mit.edu> wrote:
> 
> 
> On Jul 11, 2015, at 5:21 PM, Deborah Goldsmith <goldsmit at apple.com> wrote:
> 
>>> 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.).
>> 
>> That approach works for the Unix-level tz data. Unfortunately, it doesn’t work for the ICU open source library, which is a core component of OS X, iOS, Android, and other systems.
> 
> Presumably ICU can, at least, reload whatever form of tzdata it uses when the system time zone changes (I didn't have to reboot my Mac when I flew from California to Pennsylvania a few years ago, and a lot of the GUI-based software I was using was presumably using ICU), so there is - at least in OS X's and presumably iOS's version of ICU - presumably at least *some* of the mechanism in place to allow it to update the information for the current time zone without having to restart the process.
> 
> So why would updating ICU's time zone data not be doable with the same mechanism that could be used for UN*X's time zone data?
> 
>> Also, the relevant people at Apple are definitely aware that there is room for improvement to the current process.
>> 
>> The fact remains, the more quickly IANA releases tz updates, the more quickly tz clients (not just Apple) can get those new versions into the hands of customers. By all means, we should take the time to make sure an update is solid, but I don’t think sitting on it on the chance it might change again is necessary, unless there’s some concrete evidence that it might change again.
> 
> Paul said:
> 
>> I'd be surprised if a new version came out all that soon.  The Uruguay change doesn't take effect for three months, so there's no rush for organizations that can turn around tz changes relatively quickly.  Conversely, projects that take many months to upgrade will be late no matter what we do.
>> 
>> That being said, we shouldn't wait indefinitely for a new version.
> 
> so he's not proposing sitting on it forever.  However, he also said:
> 
>> Have we verified the upcoming Uruguay change?  Not really, not nearly as much as (say) we verified the most-recent US change -- and even if we had better confirmation, the Uruguayan change is controversial and perhaps they'll change their minds.
> 
> so the question is how long should we wait to see if Uruguay changes their mind.
> 
> And, given that:
> 
>> Downstream users of the tz database need to be reasonably prompt in applying new releases anyway.  Governments sometimes decide changes only a few days before they take effect, so if users care about timestamps, OS release schedules simply cannot require three-month delays. This is true regardless of whether we issue a new Uruguayan-related tz release this week or next week.
> 
> the only change to which I'd make is to replace "OS release schedules" with "OS supplier time zone data release schedules", as that wording leaves open the possibility of *not* tying time zone data releases to full OS releases. I, at least, think not tying them together is something worth considering, given that governments don't, in general, ask Apple and Oracle and HP and IBM and Red Hat and Novell and... when they should make time zone changes so as to avoid making any of them have to scramble to get a new release out the door or have to make their customers put up with several months of incorrect time zone data.