[tz] Turkey delays winter time

[Deborah Goldsmith]

The fact that notice is too short sometimes to respond doesn’t mean it’s desirable to follow a process that makes it less likely there will be time to respond. Large organizations like Google, Microsoft, and Apple that ship consumer products to largely nontechnical users have a different release process than Ubuntu or Red Hat. This release process can take weeks. Clients using ICU (Google and Apple at least) have to wait a few days just for the ICU team to release any corresponding changes that are needed in the ICU metazone data.

Having said that, I fully agree with the desire to hold off making a release until there is solid confirmation. But that’s different from waiting until shortly before a change takes effect in case there is an unforeseen change, or to collect multiple changes into one release. It seems reasonable to me to release a TZ update as soon as there’s confirmation that the change is correct, to give client organizations as much time as possible to package and release it. Yes, sometimes that won’t be soon enough. But we can try to make such times less frequent.

Deborah

> On Sep 19, 2015, at 10:01 AM, Paul Eggert <eggert at CS.UCLA.EDU> wrote:
> 
> John Hawkinson wrote:
>> I thought the discussion this summer had made it clear that for
>> many if not most of the downstream consumers of the tz database,
>> a change less than two months away is indeed quite a rush.
> 
> Two months is not a rush.
> 
> That discussion made clear that some development organizations had an unrealistic expectation for how much notice they can expect to receive before time zone or daylight-saving changes. Any maintenance procedure that requires two months' advance notice is doomed to fail no matter what tzdata does, because governments often change the clocks with only a few days' notice. This can be seen not only from the most recent change for North Korea, but also from this year's changes for Egypt, Mongolia, and Palestine, and many more changes in the not-too-distant past.
> 
> Like it or not, development organizations need to get time zone fixes out to their users reasonably quickly. Ubuntu has done it in less than 24 hours. Red Hat says they need five business days. That's the sort of thing developers need to do. Ideally it should take less than a day. If it takes longer than a week, something's wrong.
> 
> As I understand it, although Apple formerly required many months' lead time, it is working on speeding up its development and distribution processes for time zone data. This will be a good thing for its users. Let's hope other laggards follow suit.