Daylight saving time

Last week I got a headache from discussions about the daylight saving time and how to handle these transitions in software applications. To stop my frustration about this issue, I need some kind of closure and hopefully I can do this with writing down my point of view in this blogpost ...

Daylight saving time (DST) is the convention of advancing clocks so that afternoons have more daylight and mornings have less. Typically clocks are adjusted forward one hour near the start of spring and are adjusted backward in autumn.

DST (also called summer time) is common in Europe but this convention is not used everywhere in the world. The European Union shifts time zones all at once, at 01:00 Coordinated Universal Time (UTC). Belgium lies in the UTC/GMT +1 time zone. This means that the daylight saving time shift occurs at 02:00 local time. For 2007, the switch to summer time occurs on March 25, 02:00 local time : clocks are turned forward 1 hour to 03:00 local time. This means that the UTC offset is now +2 instead of +1. The switch to winter time in 2007 occurs on October 28, 03:00 local time : clocks are turned backward 1 hour to 02:00 local time. The UTC offset is set back to +1.

The problem in software applications is that you have days with 23 hours and days with 25 hours when using local time. If we take a closer look at a 25-hour day in Belgium, we can see that we have two runs of local hour 02:00 - one normal run and one run after the daylight saving time switch. If you store datetime information in local time, you won't be able to get the difference between the first run and the second run. Therefore, you should store all datetime information in UTC time instead of local time. UTC time makes sure that all days have 24 hours. Local time will only be used to display datetime information in your user interface and conversions will be made from local time to a UTC time and from UTC time to local time. These conversions are only required in the user interface and all other datetime information in the backend needs to be set in UTC time.

In .NET, a ToUniversalTime method exists on the DateTime object to convert a local time to UTC0 and a ToLocalTime method exists on the DateTime object to convert a UTC0 time to local time. So, if you don't want to make it more complex and don't want to write some extra conversion functions, you will agree that storing all datetime information needs to be done in UTC0 time. Right?! I don't want to go into details, but you may store datetime information in no matter what UTC time (never local time!), but UTC0 will be the best and most obvious choice. Manually adding/subtracting hours to DateTime objects in code to comply to a specific UTC time should be avoided at all cost. Always use the out-of-the-box conversions on the DateTime object. When your application has interfaces/contracts with other applications, you should try to agree on passing datetime information in UTC0 as well. If you start mixing different UTC times, you will notice that it becomes more difficult to smoothly maintain/convert all datetime information. In situations where other applications want to deliver information to you in UTCx time where x is not 0 (due to history or other bad/wrong reasons), you still want to convert all datetime information to UTC0 in your backend application. Of course : you don't have to believe me! Try it out for yourself and see how it works out ...

Wikipedia links :

• Daylight saving time
• Coordinated Universal Time