[tz] Magallanes region from Chile will keep DST all year round

[Deborah Goldsmith]

The point is, many TZ clients (not just Apple, not just ICU) consider a change that takes effect in 3 1/2 months “urgent.” It is not just a matter of development cycles; it’s also a matter of release cycles.

There are some TZ clients who can turn a change around in a few days, and there are some that require much more lead time. Telling the latter that it’s their problem they have a different business model from the former is not productive.

Debbie

> On Jan 24, 2017, at 8:32 AM, Paul Eggert <eggert at CS.UCLA.EDU> wrote:
> 
> On 01/23/2017 04:35 PM, Deborah Goldsmith wrote:
>> If it’s unimportant to release this change early, why can’t people just wait before they turn the crank if they don’t care about it?
> 
> Because it takes work to decide whether to wait. We've had a
> longstanding tradition to not release tzdb versions merely because of
> trivial or non-urgent changes, based on the principle that we often get
> short notice anyway and so any redistribution should work on short
> notice, and that omitting unnecessary releases saves everybody time. If
> we started to release more often, we would in effect be asking every
> downstream developer and distributor to inspect every release and decide
> whether that release's changes are important and urgent enough for them
> to update.
> 
> If the problem is that ICU won't look at tzdata except just after an
> "official" tzdb release and that the ICU folks then take some time to do
> translations and that Apple won't use the new tzdb update until after
> ICU has done their translations, then that leisurely process needs to be
> streamlined regardless of tzdb's version numbering scheme. If this
> diagnosis is correct, I suggest that Apple work with ICU to have a more
> incremental process where ICU does not wait until an "official" tzdb
> release before starting work on translating changes. This should not
> involve any major technical change on ICU's side (they merely need to
> use version 2016j-38-g46c2bbf instead of version 2016j, say). ICU will
> have to track tzdb more closely, but that will be true no matter what
> version-numbering scheme is used. The main problem here is the delay in
> downstream translation, not in whether the current tzdb version is
> called '2016j-38-g46c2bbf' or '2017a'.