[tz] Uruguay out of DST
pganssle at gmail.com
Sun Jul 12 21:28:50 UTC 2015
Certainly a good point, consider my statement appropriately appended.
Still, it's probably worth perspective here. It's Uruguay, not China, and
Paul is talking about waiting a bit longer to release the unstable version,
not delaying indefinitely.
Either way there could be inconveniences, and I don't think the magnitude
of the inconveniences would be particularly high, on a global scale on
either side. Still, I have no stake in the game, really - I haven't felt
much pressure to be on the bleeding edge of the time zone releases in the
things I work on, so I probably shouldn't have chimed in in the first place.
On Jul 12, 2015 5:00 PM, "Matt Johnson" <mj1856 at hotmail.com> wrote:
> > *... 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
> *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> wrote:
> On Sat, Jul 11, 2015 at 11:16 AM, Guy Harris <guy at alum.mit.edu> wrote:
> > On Jul 11, 2015, at 9:34 AM, enh <enh at google.com> wrote:
> >> On Sat, Jul 11, 2015 at 12:11 AM, Guy Harris <guy at alum.mit.edu> wrote:
> >>> On Jul 10, 2015, at 11:54 PM, enh <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
> 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...
More information about the tz