Managing culture issues in .NET programming, a headache for programmer – TimeZone Object

A time zone is a region on Earth with uniform standard time (UT) and have a legally defined borders which coincide with the border of country or some subdivision for commercial, legal and social purposes. 15 longitudinal degrees, the time changes by one hour. Thus, there are 24 time zones in the world. Over the period, local governments of various countries have altered, accepted or rejected GMT (Greenwich Mean Time) as they saw fit per their country’s requirements.

What is TimeZone Object?

TimeZone object in .NET framework represents the current local time zone.

A time zone is a geographical region in which the same standard time is used. Programmer (Software Developer) can use the TimeZone class of .NET Framework to retrieve information about the current time zone and to convert local time to Coordinated Universal Time (UTC) or vice versa. Inheritance hierarchy is System.Object - > System.TimeZone.

Below is the syntax to get the local time zone and based on that the current Coordinated Universal Time (UTC) is retrieved.

TimeZone {localZone} = TimeZone.CurrentTimeZone;

DateTime {currentUTC} = localZone.ToUniversalTime( currentDate );

The format of the date and time string in time zone will be ISO-8601 as shown below.

2016-10-13T10:20:20.20Z 

Date: YYYY-MM-dd, Time: hh:mm:ss.ms, Time zone: Z for UTC

There is lot of flexibility in the ISO-8601 format for example, we could have easily replaced the ‘Z’ at the end with a proper time zone offset like -0530 (India).
 

Why is it difficult to manage?

Many systems are dependent on keeping accurate time. The problem arises when time changes due to daylight savings like moving the clock forward or backwards. Software applications are so dumb that they don’t understand such human actions!
 

Common mistakes by programmers

Issue arises when Time zone gets changed

Let us understand this by an illustration. Assume that the customer’s main business is out of USA and their servers are hosted in France. The customer has their employees spread across multiple countries (ex: India, Indonesia, Japan and Canada).

Converting date and time string values back and forth between different cultures normally causes an issue in software applications and break them.

Solution: During implementation, when you are referring to an exact time, persist the time according to a unified standard that is not affected by daylight savings or any such actions. (GMT and UTC are equivalent with this regard, but it is preferred to use the term UTC. Notice that UTC is also known as Zulu or Z time.)

Architecture for the solution looks as shown in the below picture, showing what date time format is passed between different layers.
 

Developers are advised to apply some basic rules between multiple layers.

• Database: Everything that goes in and out is going to be UTC
• Server: Everything that goes in and out is going to be UTC
• The client (front-end) : Everything that goes in and out is going to be UTC

The time zone offsets are not always an integer number of hours (for example, Nepal uses UTC+05:45, Indian Standard Time is UTC+05:30).
 

Conclusion:

• Timestamps are suggested to be stored in UTC
• Date and time math should be performed using library
• Standard time offset should be used