UTC and Day light savings nightmare.

When it comes to using date and time information in a global software application, there is a crucial need to store the date and time as UTC. The reasons being:

- Storing time in UTC on the database allows the app to render localized data correctly. [using datetimeoffset also helps. the choice is purely situational and environmental factors]

- With the cloud computing era, we may never know the geographic location of our server and therefore assuming a particular timezone in the coding or data store logic could be catastrophic. UTC solves this problem by converting the local server timezone to a standard time value that is unique at a given point on time in history.

UTC is a panacea. There are serious problems associated with UTC with regard to the daylight savings. The below examples are excerpts from an exhaustive article on MSDN(link in the references section at the end) which explains the seriousness of the problem, when left unchecked.

- The harder-to-manage case is the ambiguity case associated with parsing user input that occurs during this magical hour of daylight savings in the spring and fall.

- Presently there is no way to parse a string that represents a user's view of time and have it accurately assigned a universal time value. The reason is that people who experience daylight savings time don't live in places where the time zone is Greenwich Mean Time. Thus, it is entirely possible that someone living on the east coast of the United States types in a value like "Oct 26, 2003 01:10:00 AM".

On this particular morning, at 2:00 AM, the local clock is reset to 1:00 AM, creating a 25-hour day. Since all values of clock time between 1:00 AM and 2:00 AM occur twice on that particular morning—at least in most of the United states and Canada. The computer really has no way to know which 1:10 AM was meant—the one that occurs prior to the switch, or the one that occurs 10 minutes after the daylight savings time switch.

Similarly, your programs have to deal with the problem that happens in the springtime when, on a particular morning, there is no such time as 2:10 AM. The reason is that at 2:00 on that particular morning, the time on local clocks suddenly changes to 3:00 AM. The entire 2:00 hour never happens on this 23-hour day.

Your programs have to deal with these cases, possibly by prompting the user when you detect the ambiguity. If you aren't collecting date-time strings from users and parsing them, then you probably don't have these issues.

Recommendations:
Programs that need to determine whether a particular time falls in daylight savings time can make use of the following(in .NET):

Timezone.CurrentTimeZone.IsDaylightSavingTime(DateTimeInstance)
or
DateTimeInstance.IsDaylightSavingTime

When you are coding and desire to store current time represented as universal time, avoid calling DateTime.Now() followed by a conversion to universal time. Instead, call the DateTime.UtcNow function directly.

The impact on an application, purely depends on the type of application. The impact will be very high for financial, ecommerce, healthcare, logistics etc where time value is crucial and controls business logic.

References:

• http://msdn.microsoft.com/en-us/library/ms973825.aspx#datetime_rules
• http://msdn.microsoft.com/en-us/library/bb397769.aspx