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

[Paul G]

It seems to me that the ideal solution for "long release cycle" tzdb consumers is that essentially every commit (that constitutes a material change in the output, anyway) is a release, at which point why not just pull directly from the master branch of the git repository and treat it as a "patch" release?

I can see the point of more frequent releases if downstream consumers can meaningfully talk about the version number of the compiled tzdb, but that information isn't included in any standardized way. Presumably if such a version scheme is implemented, it would then be reasonable to have intermediate versions like 2017a-05 or something like that, "tag only" releases for people who need a long lead time.

That said, given the frequency with which time zone changes come at the last minute, it does seem pretty valid to say that if your tzdb update cycle is 3 months long, you're in trouble no matter what the official release cycle is.

On 01/24/2017 02:51 PM, Deborah Goldsmith wrote:
> 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'.
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mm.icann.org/pipermail/tz/attachments/20170124/48918fd0/signature.asc>