Avoiding time confusion


Changing the clock confuses humans and computers as well

This weekend all over the world hundreds of servers went down, millions of transactions failed and data was lost due to daylight saving time confusion. This recurring event happens every time we change the clock between winter / summer time because of daylight saving time. In this article I explain the cause of the problem. I also provide some hints on how to prevent these kind of problems.


Wikipedia: Daylight saving time (DST) is the practice of advancing clocks during summer months by one hour so that evening daylight lasts an hour longer, while sacrificing normal sunrise times. Typically, regions that use Daylight Savings Time adjust clocks forward one hour close to the start of spring and adjust them backward in the autumn to standard time.[1]

DST clock shifts sometimes complicate timekeeping and can disrupt travel, billing, record keeping, medical devices, heavy equipment,[6] and sleep patterns.[7] Computer software often adjusts clocks automatically, but policy changes by various jurisdictions of DST dates and timings may be confusing.[8]

What causes these problems

When computers are located in different time zones they may use different time notations for an event that actually happens on the same moment. When we setup and implement our computer systems correctly this will not cause any problems. But in reality computers and people exchange data but do not always mention that the data comes from a different timezone. For example making someone living in Europe making an appointment with someone in the USA will fail if you just say “Lets have a video conference at 12:00”. Humans get confused by these situations and the same goes for computers when the assume a certain time zone.

Another cause of problems is software bugs. Because the summertime / wintertime switch is a very rare occasion this situation is often not tested at all. I found bugs in messaging software where messages containing business transactions where dropped because the receiver inspected the time stamp (just before the switch) and assumed the message was more than one hour old.

What can we do about it

As a best practice all computers that are connected to the same network should by in sync with each other and use the same time standard. Because we are connected by the internet we all should use Coordinated Universal Time (UTC).

Coordinated Universal Time (French: Temps universel coordonné), abbreviated to UTC, is the primary time standard by which the world regulates clocks and time. It is within about 1 second of mean solar time at 0° longitude;[1] it does not observe daylight saving time. It is one of several closely related successors to Greenwich Mean Time (GMT). For most purposes, UTC is considered interchangeable with GMT, but GMT is no longer precisely defined by the scientific community.

Configuring your server and applications to use UTC is the best choice because

  • UTC is an international standard
  • Allmost all computers and applications support UTC time
  • Events that occur at the same moment the time can be represented with the same notation everywhere in the world (reducing confusion)
  • Its easier to calculate time intervals using UTC time

UTC time does not have a notion of timezone and daylight saving. Its just a clock that keeps on ticking by adding seconds since the beginning of time. Once a year a leap second is added because the rotation of the world is slowing down. By using a  monotonously increasing UTC time computers are not confused by sudden changes in time due to moving clocks forward and backwards. We humans still like to use local time. For this we can use some utility functions that translate UTC time in local time or vice versa.


You should read the manuals of all you critical software systems and find out what they have to say about time.

As an extra precaution you could find out how your system reacts during a DST change. For this you have to setup an end-to-end test environment. Change all clocks some minutes before the DST switch, generate some activity and observe what happens.


  • Be aware of time and DST related problems
  • Keep your servers and applications clocks in sync
  • Use UTC time on your server and data stores such as databases
  • Use local time only for reporting
  • Always verify that data is in UTC format before importing into your system
  • Test, test, test

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s