[tz] Uruguay out of DST

[Steven R. Loomis]

Replying to an older message in the thread..

Enviado desde nuestro iPhone.

On Jul 11, 2015, at 5:47 PM, Guy Harris <guy at alum.mit.edu> wrote:

>> 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 …
> 
> 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?

The cause is caching of data much more complex than typical un*x time services.  You can in fact reload Icu without a process restart, but not while any threads are using any services or have service objects allocated.  

Also if a weekly calendar were in the middle of painting when an update came; it could be unexpected to see part of the week with a shifted offset. Even if there were a portable way to get notification of file/network updates an app would have opinions on how changes are made. It's as if I had "int a=3; sleep(); int b=3; if(a==b)…" I would not expect a and b to be different from each other, but that's what a tz rule change would do. In a modern highly composed application, when are you really sure that *all* libraries on all threads are ready for Uruguay's offset to change? 

That said, if anyone wants to jump in with ideas, ICU is open source and could with some engineering perhaps lend itself to experimental use of tzdist or other options. Let me know offline if anyone needs pointers on getting started. End plug.  

Steven.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20150723/b1fafd63/attachment-0001.html>