[tz] Uruguay out of DST

[Matt Johnson]

> ... but even if so, not to be callous or anything, but this only affects people in areas where time zones are unstable on short notice.

 

That's not necessarily true.  It also affects anyone that interacts with that time zone.  For example, I may be in the United States, but scheduling an online meeting or a phone call with someone in Uruguay.  If only the person in Uruguay has the updated time zone information, I might contact them at the wrong time.

 

TZ updates for any zone should be distributed as widely as possible.  Not just to those in that particular zone.

 

 

From: tz-bounces at iana.org [mailto:tz-bounces at iana.org] On Behalf Of Paul Ganssle
Sent: Saturday, July 11, 2015 12:55 PM
Cc: tz at iana.org List
Subject: Re: [tz] Uruguay out of DST

 

I find it hard to believe that anything as a full OS update is required to update time zone data, but even if so, not to be callous or anything, but this only affects people in areas where time zones are unstable on short notice. This is probably a fairly small number of people in the scheme of things, and it's not like the inconvenience would persist indefinitely.

The fact that the unstable version is updated almost immediately seems to be a decent mitigation strategy for critical applications, but I'm perfectly fine deferring to Paul's judgment on this rather than jumping through hoops to accommodate crazy time zone authorities who change things like this on very little notice.

On Jul 11, 2015 2:35 PM, "enh" <enh at google.com <mailto:enh at google.com> > wrote:

On Sat, Jul 11, 2015 at 11:16 AM, Guy Harris <guy at alum.mit.edu <mailto:guy at alum.mit.edu> > wrote:
>
> On Jul 11, 2015, at 9:34 AM, enh <enh at google.com <mailto:enh at google.com> > wrote:
>
>> On Sat, Jul 11, 2015 at 12:11 AM, Guy Harris <guy at alum.mit.edu <mailto:guy at alum.mit.edu> > wrote:
>>>
>>> On Jul 10, 2015, at 11:54 PM, enh <enh at google.com <mailto:enh at google.com> > wrote:
>>>
>>>> it is, unfortunately, the world we live in.
>>>
>>> Who's "we",
>>
>> between Android and iOS, the majority of people with computing devices.
>>
>>> why does "our" operating system not allow the tz database files to be updated without doing a complete new OS release or something as heavyweight as that, and how do we fix that?
>>
>> how things look in the future is a separate discussion. we're talking
>> about the practicalities of getting tzdata into users' hands _today_.
>
> So what's the time frame difference between "today" and "the future"?
>
> I.e., how soon can various vendors - including *but not limited to* Apple and Google, given that there are also a number of significant computing devices out there that run neither Android nor iOS (and without which a lot of those Android and iOS machines won't be able to get very much interesting stuff from the Interwebs) - deploy mechanisms to update time zone files without having to spin an entire OS release just to note that Elbonia is changing to start using DST?
>
> "Mechanisms" here includes both "a way by which an update can be pushed to machines, preferably without requiring a reboot" and "a way by which the vendor's process can treat a time zone data update as being more lightweight than a full OS release".  As per my earlier mail, Apple, at least, have demonstrated that they can distribute other less-than-a-full-OS release update.
>
> So, whilst we probably shouldn't delay the Uruguay update *too* much, ultimately this needs some effort on the part of distributors.  The governments of the world, sadly, don't pay much attention to vendor release schedules when making changes to their DST rules, so, sadly, there *will* be times when a necessary time zone database won't line up nicely with an OS update.

no one is arguing otherwise. but in the meantime, the less time spent
sitting on updates without a good reason to delay, the worse for
everyone.

--
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20150712/0efbf86e/attachment.html>