Hi All, According to news published an hour ago government (Turkey) will postpone end of summer time to 8th of November due to the security issues related with the national election that will be held on 1st Nov. I will confirm from the government agency soon. Best regards. Fatih, WorldClock.com™ <https://t.yesware.com/tl/a9ae0329641b7dd629a1f9fbd15b34b7a31e117f/81cac01ffb...>
Fatih wrote:
According to news published an hour ago government (Turkey) will postpone end of summer time to 8th of November due to the security issues related with the national election that will be held on 1st Nov.
Thanks for the heads-up. There's no rush as the change wouldn't take effect for more than a month, and we can wait for official confirmation. Election security in Turkey is a serious business, often with some fatalities involved. Let's hope this time works better than the last time the Turkish government futzed with daylight saving time while conducting an election: http://www.balkaneu.com/eventful-elections-turkey/
Paul Eggert <eggert@cs.ucla.edu> wrote on Sat, 19 Sep 2015 at 08:28:40 -0700 in <55FD7F28.3030302@cs.ucla.edu>:
Thanks for the heads-up. There's no rush as the change wouldn't take effect for more than a month, and we can wait for official confirmation.
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. I think we could still stand to have much better clarity and consistency of expectations on release frequency. --jhawk@mit.edu John Hawkinson
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.
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@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.
Deborah Goldsmith wrote:
It seems reasonable to me to release a TZ update as soon as there’s confirmation that the change is correct
Sometimes even after we have confirmation, a government changes its mind and un-confirms. And in the more usual case where a government stands pat, there is an advantage to batching changes rather than generating a new tzdata release for each individual change. Doing the latter would have doubled the number of tzdata releases this year. There is a cost to making tzdata releases, and we shouldn't inflict that cost on everybody merely because some organizations' release processes are so slow that they'll have problems no matter what tzdata does. The situation in Turkey is strange. It seems that the news was reported in a major Turkish newpaper on September 8. Only yesterday were we informed. As far as we know, there's been no government announcement. The last time Turkey tried this sort of thing, it didn't take: only parts of the government observed the official time, and civil society (e.g., airlines) ignored the change. It's not clear what will happen this time, even if we get confirmation from some agency of the Turkish government. Quite possibly Apple and the tzdata project will get complaints no matter what we do. Let the fingerpointing begin!
If you guys want you can blame me. I've been looking for a new career as a scapegoat ever since my previous gig as a regular goat fell through - turns out eating cans and wearing square pupil contact lenses doesn't make you any better at producing humboldt fog. On Sun, Sep 20, 2015 at 3:14 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
Deborah Goldsmith wrote:
It seems reasonable to me to release a TZ update as soon as there’s confirmation that the change is correct
Sometimes even after we have confirmation, a government changes its mind and un-confirms.
And in the more usual case where a government stands pat, there is an advantage to batching changes rather than generating a new tzdata release for each individual change. Doing the latter would have doubled the number of tzdata releases this year. There is a cost to making tzdata releases, and we shouldn't inflict that cost on everybody merely because some organizations' release processes are so slow that they'll have problems no matter what tzdata does.
The situation in Turkey is strange. It seems that the news was reported in a major Turkish newpaper on September 8. Only yesterday were we informed. As far as we know, there's been no government announcement. The last time Turkey tried this sort of thing, it didn't take: only parts of the government observed the official time, and civil society (e.g., airlines) ignored the change. It's not clear what will happen this time, even if we get confirmation from some agency of the Turkish government. Quite possibly Apple and the tzdata project will get complaints no matter what we do. Let the fingerpointing begin!
If the Turkey change is still not confirmed, or is in doubt, then we should wait for further confirmation, I agree.
And in the more usual case where a government stands pat, there is an advantage to batching changes rather than generating a new tzdata release for each individual change. Doing the latter would have doubled the number of tzdata releases this year. There is a cost to making tzdata releases, and we shouldn’t inflict that cost on everybody merely because some organizations' release processes are so slow that they'll have problems no matter what tzdata does.
First, “some organizations” correspond to the vast majority of end users using the TZ data: all the major consumer OS vendors. So to claim the current process is working except for “some organizations” doesn’t really reflect the impact on, literally, billions of people. Part of the reason it takes those organizations a while to process an update is that, in general, when you’re pushing bits to hundreds of millions of devices you need to do thorough testing. There are also release cycles, as users don’t like to be bombarded with requests to update their devices too frequently. It’s not because we’re slow for the fun of it, or because we’re burdened with bureaucracy: the business model for consumer devices is different from Red Hat or Ubuntu. There is little impact to client organizations from having more TZ releases. They are free to not pick up every single one. It seems to me that delivering changes ASAP is a higher priority: that gives maximum flexibility to client organizations. If there is impact on IANA from releasing more frequent updates, then we should definitely discuss it. But if it’s just counting releases, why does anyone care if there are twice as many? Yes, sometimes governments change their minds. Then we’re pretty much hosed no matter what. And we can always back out a change before it’s released if a government changes its mind. Deborah
On Sep 20, 2015, at 12:14 PM, Paul Eggert <eggert@CS.UCLA.EDU> wrote:
Deborah Goldsmith wrote:
It seems reasonable to me to release a TZ update as soon as there’s confirmation that the change is correct
Sometimes even after we have confirmation, a government changes its mind and un-confirms.
And in the more usual case where a government stands pat, there is an advantage to batching changes rather than generating a new tzdata release for each individual change. Doing the latter would have doubled the number of tzdata releases this year. There is a cost to making tzdata releases, and we shouldn't inflict that cost on everybody merely because some organizations' release processes are so slow that they'll have problems no matter what tzdata does.
The situation in Turkey is strange. It seems that the news was reported in a major Turkish newpaper on September 8. Only yesterday were we informed. As far as we know, there's been no government announcement. The last time Turkey tried this sort of thing, it didn't take: only parts of the government observed the official time, and civil society (e.g., airlines) ignored the change. It's not clear what will happen this time, even if we get confirmation from some agency of the Turkish government. Quite possibly Apple and the tzdata project will get complaints no matter what we do. Let the fingerpointing begin!
On 09/21/2015 01:41 PM, Deborah Goldsmith wrote:
when you’re pushing bits to hundreds of millions of devices you need to do thorough testing. There are also release cycles, as users don’t like to be bombarded with requests to update their devices too frequently
Red Hat and Ubuntu have tens of millions of users. This difference in scale does not explain why Apple can take over six months to propagate a small change to time zone data, whereas Ubuntu can do it in a few hours. More plausibly, the difference comes from Apple bundling time zone data into its operating systems and requiring a full test cycle and OS upgrade in order to install fixes, whereas Red Hat, Ubuntu, etc. treat time zone data separately and routinely issue minor updates for just a few small files, which can be tested separately. The incremental approach is better for end users and for developers and for testers, and one way or another Apple needs to change its software process to support it. Any such change is needed regardless of what tzdata does, because governments typically don't notify us a year in advance. Of course a development-organization battleship cannot turn on a dime, but that's OK; there's no rush, as in the meantime you can cherry-pick changes from the experimental version on Github as needed.
If there is impact on IANA from releasing more frequent updates
There is some impact on IANA, though not much: they are mostly just hosting the data. There is more impact on me, and on development organizations downstream from tzdata. Every time I do a release, I check over the distribution; some of this work is automated and some is not. My work is volunteer and my time is limited. The situation is similar for many other downstream developers. Most do not have the resources of Ubuntu or Red Hat, much less Apple or Google.
I'm from Turkey and *still *there is no official announcement about this delay as far as I know. Looks like Sozcu newspaper ( http://www.sozcu.com.tr/2015/gunun-icinden/saatler-ne-zaman-geri-alinacak-ya...) wrote it without any official announcement. I tweeted and mailed to them but no feedback yet. Usually, these DST changes announce in Resmi Gazete ( http://www.resmigazete.gov.tr/default.aspx) as Matt mentioned. But there is no announcement for this. 1,5 hour ago a new topic published in Haberturk ( http://www.haberturk.com/ekonomi/enerji/haber/1131744-kis-saati-uygulamasi-e...) on this topic. And it says; Government Spokesman Numan Kurtulmuş (
https://en.wikipedia.org/wiki/Numan_Kurtulmu%C5%9F): "Department of Energy *continues *study. *Most probably*, it will be delay 15 days ahead (from Oct 25th to Nov 8th). This is considered as one of the national selection precautions. On 8 or 9 November, DST will be canceled and it will switch to normal time."
IMHO, it is *okey *to update tz database as Paul did. On Tue, Sep 22, 2015 at 12:48 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 09/21/2015 01:41 PM, Deborah Goldsmith wrote:
when you’re pushing bits to hundreds of millions of devices you need to do
thorough testing. There are also release cycles, as users don’t like to be bombarded with requests to update their devices too frequently
Red Hat and Ubuntu have tens of millions of users. This difference in scale does not explain why Apple can take over six months to propagate a small change to time zone data, whereas Ubuntu can do it in a few hours. More plausibly, the difference comes from Apple bundling time zone data into its operating systems and requiring a full test cycle and OS upgrade in order to install fixes, whereas Red Hat, Ubuntu, etc. treat time zone data separately and routinely issue minor updates for just a few small files, which can be tested separately.
The incremental approach is better for end users and for developers and for testers, and one way or another Apple needs to change its software process to support it. Any such change is needed regardless of what tzdata does, because governments typically don't notify us a year in advance. Of course a development-organization battleship cannot turn on a dime, but that's OK; there's no rush, as in the meantime you can cherry-pick changes from the experimental version on Github as needed.
If there is impact on IANA from releasing more frequent updates
There is some impact on IANA, though not much: they are mostly just hosting the data. There is more impact on me, and on development organizations downstream from tzdata. Every time I do a release, I check over the distribution; some of this work is automated and some is not. My work is volunteer and my time is limited. The situation is similar for many other downstream developers. Most do not have the resources of Ubuntu or Red Hat, much less Apple or Google.
-- Soner Gönül http://sonergonul.net http://twitter.com/sonergonul
Thanks for the heads-up. That "Büyük ihtimalle" ("most probably", "presumably") suggests that the Turkish government still hasn't decided for sure, though there is (presumably :-) over a 50% chance.
After looking around a bit, I found a news article dated September 8 on the topic. I wonder why the news took so long to be known more broadly? Anyway, attached is a proposed patch to match the many news sources that talk about this. Although I have installed this in the experimental version on github, I would prefer confirmation from a more-official source before doing a tzdata release.
FWIW, I found the original order for 2015 in the official gazette, and it makes no mention of a delay. It has the original Oct 25th end date. http://www.resmigazete.gov.tr/eskiler/2015/03/20150317-2.htm This was in the March 17th 2015 issue referred to in the news article. I searched on similar Turkish keywords and found no new order indicating a delay. Either it's not published yet, or the news is bogus.
To: tz@iana.org From: eggert@cs.ucla.edu Date: Sat, 19 Sep 2015 20:04:57 -0700 CC: fatih@worldclock.com Subject: Re: [tz] Turkey delays winter time
After looking around a bit, I found a news article dated September 8 on the topic. I wonder why the news took so long to be known more broadly? Anyway, attached is a proposed patch to match the many news sources that talk about this. Although I have installed this in the experimental version on github, I would prefer confirmation from a more-official source before doing a tzdata release.
Hello, The most popular news organization Hurriyet published http://www.hurriyet.com.tr/ekonomi/30191796.asp today Accordingly, the Turkish government has approved the change. Although the change is not yet published in the 'official gazette' which takes some time, the approval process is done. This is sufficiently official to go ahead with the patch methinks. Ozgur -- Özgür Yüksel | Manager, Customer Support, Europe - Middle East - Africa Oracle Linux, Oracle VM and Private Cloud Appliance Support Phone: +90 312 248 8900 ORACLE Turkey | Dumlupinar Blv. 266 Tepe Prime A/56 Çankaya | TR-06800 Ankara
<ozgur.yuksel <at> oracle.com> writes:
Hello,
The most popular news organization Hurriyet published
Accordingly, the Turkish government has approved the change. Although
the change is not yet published in the 'official gazette' which takes
some time, the approval process is done.
This is sufficiently official to go ahead with the patch methinks.
Ozgur
There are newspapers with gov.tr domains to confirm that the Turkish government has approved the change to postpone end of DST till Nov 8, 2015. Summer will end dates of Daylight Saving Time, on November 8 was postponed from 25th October. Yaz saati uygulamasının sona ereceği tarih, 25 Ekim'den 8 Kasım'a ertelendi. http://basinilankurumu.gov.tr/8-kasim-da-sona-erecek-haberi-96024/ Daylight saving time will end on November 8 Summer will end dates of Daylight Saving Time, on November 8 was postponed from 25th October. Yaz saati uygulaması 8 Kasım'da sona erecek Yaz saati uygulamasının sona ereceği tarih, 25 Ekim'den 8 Kasım'a ertelendi. http://www.anadoluajansi.gov.tr/tr/turkiye/yaz-saati-uygulamasi-8-kasimda- sona-erecek/362217 Alexander Krivenyshev (worldtimezone.com)
participants (9)
-
Alexander Krivenyshev -
Deborah Goldsmith -
Fatih -
John Hawkinson -
Matt Johnson -
ozgur.yuksel＠oracle.com -
Paul Eggert -
Paul Ganssle -
Soner Gönül