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.