[tz] Turkey to delay DST
enh at google.com
Thu Feb 27 20:23:04 UTC 2014
certainly "the sooner the better" seems like a good rule of thumb to
me. like the others, i can upgrade to your latest release immediately
(and it's all scripted, so any given tzdata release costs me almost
nothing), but it can be a long time from then until the update gets
into users' hands.
in particular, it's non-linear; there are distinct cutoffs where a
day's difference on your end can mean several months from the users'
perspective. sadly, the last day we can get tzdata changes in is
unlikely to be something any of us can tell you :-)
the flip side is that if a release contains data you're not sure
about, it could be that users have to live with that for months
because the bad data made it in and the correction didn't. i don't
think there's anything we can do about that though; it's just the
nature of the data that it's always going to be a best guess.
1. this will be truer if/when we can wean icu4c off its own copy of
the tzdata. but that's our problem, not yours.
On Thu, Feb 27, 2014 at 12:02 PM, <Paul_Koning at dell.com> wrote:
> On Feb 27, 2014, at 2:55 PM, Deborah Goldsmith <goldsmit at apple.com> wrote:
>>> We should have a new release well before the Turkey change, yes. It doesn't seem that urgent, since it's a month from now. But if there's sentiment to push out a version now I can do that.
>> Given the software release process at many companies, “a month from now” is actually extremely urgent.
> Actually, given the software release processes some of us have, a month lead time is about an order of magnitude too small. :-(
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Java i18n/JNI/NIO, or bionic questions? Mail me/drop by/add me as a reviewer.
More information about the tz