On the Timing of Time Zone Changes

What do Turkey, Chile, Russia, Venezuela, Azerbaijan, North Korea and Haiti all have in common? Time Zone Chaos!

No, that's not the punchline to a joke.  It's actually quite a serious problem.  The biggest issue with time zones is not that they exist, nor that they have daylight saving time.  But rather, in that they often change in a haphazard manner.  Allow me to explain.

First, understand that from a global perspective, one might think that the time zones of the world should be managed by some relatively neutral international body, such as the ITU division of the United Nations, or perhaps the IAU.  However, each of the world's time zones are actually controlled from a local perspective.  Each individual nation has a sovereign right to decide the local time for the lands within their jurisdiction.  This includes both the offset from Universal Time, and the rules that govern daylight saving time, if they choose to use it.

This unto itself is not a problem, and absolutely I agree that countries should be able to do whatever they want with the clocks within their borders.  However, time and time again, we run into the same problem, which is simply that they are changed without enough notice.  All of the countries mentioned earlier have done this recently, along with many others.

It's crucial that when governments make changes to their time zones or daylight saving time rules, that they provide ample lead time for technology to catch up.  One has to consider the real work that people have to do to validate the change, create a data update, test the changes, and to publish and distribute the update.  Then you have to consider that individuals don't always update their systems instantly.  It's very common for a time zone update to be available for weeks or months before it is actually installed by the end user.

Turkey - A Case Study:

Let's look at Turkey as an example. In 2015, the government decided that it would be a good idea to delay the end of daylight saving time by two weeks to allow for more daylight hours at the polls during their election season.  They moved the end of DST date from October 25th to November 8th.

• The first word about this was from an unofficial news article on September 8th, about 6 weeks before the clocks were due to change.  However, this article wasn't noticed by the TZ community until around September 19th.  It's difficult to go off of news stories alone, as they are often wrong or fuzzy on the details.  A few words from a politician to a reporter is simply not good enough.
• On September 29th, a government news agency also reported the change.  It still wasn't fully official, as it had not come with any kind of decree or legislation.  But it was enough to convince some in the TZ community that it was real, and thus a change to the IANA TZ database was initiated, and then released a few days later on October 1st.
• The official announcement from the government finally came on October 4th, when it was published in the official gazette.  This is about three weeks official notice of the proposed change.
• Many technology vendors, including big players like Apple, Google, and Oracle, took the data from IANA and published it through their own channels.  As an example, Apple released it to iPhone and iPad devices with iOS 9.1 update, on October 21st, leaving only 3 days for users to install the update to prevent their clocks from changing on the wrong day.
• For Microsoft Windows, which follows a slightly different process and requires a higher degree of confirmation, an announcement was made on October 9th and an update was issued on October 20th.
• In some cases, the date was missed entirely, such as with pytz - the popular time zone library for the Python language, which published its version 2015.7 on October 26th.

So what was the result? Well, to quote the BBC:

Confused Turks are asking "what's the time?" after automatic clocks defied a government decision to defer a seasonal hour's change in the time.

Or as the IBT reported:

Millions of Turks woke up to a confusing morning on Sunday ... as smartphones, tablets, and computers had automatically updated in keeping with other countries in the Eastern European Time zone, even though Turkey delay setting clocks back an hour for the next two weeks.

You can imagine that this probably had exactly the opposite effect on voting than what was envisioned.  However, you think they would have known better, since almost the exact same thing happened the previous year!  As reported by the Independent Balkan News Agency in 2014:

An unbelievable confusion to 52.9 million Turkish voters was caused by the decision of the turkish government to postpone for a day the time shift applied all around the world, where the indicators are turned one hour forward. The reason for postponing the application of summer time according to the Erdogan government, was to facilitate the smooth conducting of the elections, but nobody predicted the "new technology" factor. All smart phones of the Turkish citizens changed the time automatically, resulting in thousands of voters going to the polls earlier having to wait for an hour to vote.

Similar problems were also caused to computers that had not downloaded a new version of the software. Problems also occurred in the luggage delivery system at Istanbul’s airport as the system automatically changed the time, ignoring the government’s plans and as a result the luggage were delivered to the passengers with great delay. There were also problems with many flights as passengers were confusing their departure time.

What about the rest of the world?

Not only did Turkey not learn from their own mistakes, but other countries around the world also have failed to learn from the experience and continue to have this problem.  Remember the list I rattled off earlier?  Let's take a closer look:

• Chile had been on "permanent DST" in 2015, but on March 13th, 2016, the government announced they would return to Standard time starting May 15th, 2016 (two months notice).
• Russia has 11 distinct time zone offsets, ranging from UTC+02 through UTC+12, with a complex history of changes in the boundaries between them. For 2016, six regions changed their time zones on March 27, 2016. Each of these regions had their own law placing the change into effect.  One was signed on December 30th (12 weeks notice), which is reasonable.  The others however were signed on either February 15th (6 weeks notice) or March 9th (2 weeks notice). Two other regions had pending legislation during this period, one of which didn't pass until April 5th, of which its effective date was stretched out until April 24th (3 weeks notice).  The other is still awaiting its final signature by the President, which is expected to occur in the next few days, and has an effective date of May 29th (4 weeks notice).  (Update: It was passed on April 26th.)
• Venezuela had been on UTC-4:30 since 2007, but the government recently decided that it would return to UTC-4 on May 1st, 2016.  The change was first announced on April 15th, then became official on April 18th when it was published in the country's Gazette (2 weeks notice).
• Azerbaijan canceled DST permanently in 2016.  It was scheduled to go into effect on March 27th, but the cancellation wasn't announced until March 17th (10 days notice).
• North Korea moved from UTC-9 to UTC-8:30 on August 15th, 2015.  The change was announced on August 7th.  (8 days notice)
• Haiti canceled DST for at least the 2016 calendar year.  It was scheduled to go into effect on March 13th, but on March 12th (just 1 day notice!) the government issued a press release canceling it.

Other Timing Issues

While all of the above changes come with a certain degree of surprise, there are other some parts of the world that simply don't make any advanced schedule at all for their daylight saving time rules.

Fiji is one such time zone.  It has had DST every year since 2009.  However, each year, the government issues an announcement stating what date it will begin and end.  It's slightly different each year, and it's unclear exactly when the government will reach their decisions, or what to do in the absence of an announcement.  It would be much simpler if they would just decide on a regular schedule, and only make announcements if there are deviations from that schedule.

Another such place is Morocco, where the schedule for the first start of DST and last end of DST are adequately defined, but every year since 2012 there has been a "DST suspension period", such that DST ends before the start of Ramadan, and is restored sometime after.  Not only does this mean that the clocks need to be changed four times in a single calendar year, but it also means that nobody is fully certain of when the middle two transitions will occur until the government makes an announcement.  Part of the reason for this is that the dates for Ramadan are based on the observed sighting of the new moon.  However, my personal opinion is that they should still fix the DST transitions to some schedule, even if it starts before Ramadan and ends sometime after.  The unpredictability of the dates makes it just too difficult to know what time it is in Morocco unless you are are actually there.  (By the way, Egypt used to do this as well, but only in 2010 and 2014.)

Recommendations to the World's Governments

First, I must emphasize that these are my personal recommendations.  I am not speaking on behalf of my government, my employer, nor the TZ community.  These recommendations are based on years of experience working with time zone data in computing, and the observation of real events.

If you're going to make changes to your time zone(s), whether they are for the standard time offset from UTC, or to the enactment or abolishment of daylight saving time, or to the dates and times that daylight saving time occurs then please do all of the following:

1. Give ample notice, preferably at least 6 months in advance of the change.  One year or more would be even better.
2. Provide that notice via an official government decree or passage of a law.  Publish the law, and make it available online on an official government web site.
3. Be sure to include the precise details of the change, including the date and the time of day that the change is to go into effect.  For example, state "the clocks will advance forward by 30 minutes on April 1st, 2017 at 01:00 local time".  Do not just say "The time will change in April".  Also, if the change only affects a particular region of your country, please specify the exact areas that are affected.
4. Notify your citizens and the world via press releases and the news media, but do not rely solely on this to communicate the change.  The official decree or law should trump any statement made to the press.
5. Send notification to the TZ community.  To do this, simply send an email to tz@iana.org, which is the address for the tz discussion list.  The email should contain a URL to the announcement published on an official government web site.
6. If the change is to be aborted, please give ample notice of that as well.

Following these guidelines will ensure that your change is observed by technology, including computers, cell phones, and other devices.

Recommendations to Software Developers

1. Don't try to invent your own time zones, or hard-code a list of time zones into your application.
2. Let the features of your platform or library perform time zone conversions.  Don't attempt to codify the rules on your own.
3. Don't rely solely on fixed offsets from UTC, nor make any assumptions about daylight saving time for a particular time zone.
4. Stay on top of time zone updates.  Be sure you know how to keep current, using the mechanisms of your platform or library.
5. Subscribe to the TZ Announcements mailing list, so you know when a new time zone update is available.
6. If you have knowledge of an upcoming time zone change in a particular area that deviates from the currently known information, or if you have other questions about time zones in computing, join the TZ Discussion mailing list.
7. Use timeanddate.com to validate any assumptions you have about the time zones for a particular region.  The accuracy of this particular site is well established, and  its owners participate in the TZ community.
8. For Windows, .NET, and other Microsoft products, watch the news feed on this site so you know when platform updates are available.  (Though you should prefer IANA time zones whenever possible, even if it means using a library to do so.)