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@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'.