In this post we will be discussing about time zone, its effect on applications, way to efficiently implement the time zone and much more. So let’s start.

What Time zone actually is: As Wikipedia says “A time zone is a region that has a uniform standard time for legal, commercial, and social purposes. It is convenient for areas in close commercial or other communication to keep the same time, so time zones tend to follow the boundaries of countries and their subdivisions. ”

So basically different sub regions follow different time zones like India follows IST , Britain follow BST and like these there are many more. We consider UTC as the base time zone and define others, in terms of hours lag, on a negative to positive scale of UTC. Like IST (UTC + 5:30 hours).


What do developers care about?

When we are developing an application which is going to cater a large set of users located across different regions of world, we surely need to handle time zone in a very effective way. Even if we are targeting a single country we have to take time zone into account as even in a single country we can have more than one time zone.

Date time in applications is used to record the exact moment of the occurrence of events or transactions. All the functionalities which are dependent on date times should be built taking time zone effects in mind.



Suppose few end users sitting in different time zones are navigating through the volume or managerial reports which contain some date time entries. Respective users should be able to see the date times as per their time zones. If a task has created date time as 25 Oct 9 pm for an IST user then it should be shown as 25 Oct 3:30 pm to a UTC user, so that the users have an exact knowledge of the occurrence of events.

If a particular task is bound to SLA and an end user doesn’t get its correct origination time because he/she is sitting in a different time zone then it may create a hell lot of problem.


We have to take care of the date time fields in an application at two points to efficiently implement the time zone functionality.

  • Handling all the transaction related to the date time and saving them to the back end.
  • Showing the date time fields to an end user.

Transaction with Date time fields:

For transactions with date time fields we have to take care of time zone. It may be implemented by making all the transaction in a desired time zone and then finally saving the fields in the back end after converting them to UTC.

What is desirable!

Selecting a time zone for the transactions depends on the business logic that an application serves. We assign a time zone to an end user based on the needs of the application.

Suppose there is a very simple app whose end users may be sitting anywhere on the earth. We may directly find the time zone of the end user through its browser and make all the transactions with the user time zone and then finally convert the date time fields in UTC and save it to the database.

But what if the structure of the application differentiates its users based on some facts other than their individual time zone. For example suppose there is an application that divides the whole process based on regions like NASA and EMEAC or like any other way suppose the application has few groups say randomly A ,B and C. Now all the End users that has to deal with group A will come under IST, all in B will come under EST and those under C will come under MST. So in this case all the transaction will occur considering the group time zone. For example users create a task in group A so the task creation dates time will be according to IST even if the user is sitting in Arizona which follows Mountain Standard Time (MST).

Showing the date time fields to the end user:

It’s relatively an easy task we need to find out the time zone of the logged in user and convert the date fields retrieved from database from UTC to the user’s time zone.

Is time zone completed conceptually?

Yes almost except DST (Daylight Saving Time)

So what is DST?

As Wiki says it is the practice of advancing clocks during summer months (that feature more daylight) so that people get up earlier in the morning and experience more daylight in the evening. Typically, users of DST adjust clocks forward one hour near the start of spring and adjust them backward in the autumn.

For more info on it do visit DST section of

The list of DST for various countries around the globe for the year 2014 can be found in this link:

Plain meaning and effect on time zone: Suppose in London the clocks are moved forward by one hour from 30 Mar 2014 2 Am to 26 Oct 2014 1 Am.


It means in 2014 London will be following GMT or UTC + 1 hour from 30 MAR 2 Am to 26 OCT 1 Am and outside this frame of time it follow UTC.

Conceptually it may be easily understood but technically there are many questions that do arise in mind like:

  • How to handle DST along with the time zone concept.
  • Will the clocks be moved 1 hour every time?
  • Are these dates constant or these dates vary every year and if they do vary then how come a developer will get to know that from when to when the DST will be applied.
  • Does every city or country inside a time zone follows DST or not and if not then how we are going to handle it for individual countries?

Technically for implementing of complete time zone concept we will be discussing everything later on but for few conceptual clearing following points will help:

  • DST can be easily handled alongside time zone. Whenever we will be converting the date time fields from UTC to a time zone say BST or EST, we will put an extra check on the current date time and if the time zone is under DST at the current time then we will take into account of that extra one hour added because of the DST.
  • No the clocks will not always be moved by one hour. In past there are years when the clocks are moved from 30 minutes to even 2 hours.
  • These dates are not hard coded dates and they may vary every year. An application is not built for just one year every year so we have to take care of DST very year for our application. Ideal case would be if we can create a configurable system that can detect the start of DST but unfortunately there isn’t any pattern that can be applied for the complete world. Some say that it will start from 2nd Sunday of March and will end on first Sunday of November but this is not right in context of all the countries.
  • Every country does not follow DST like India does not follow. Even countries /cities within the same time zone do not necessarily follow DST. For example Denver and Arizona lies under MST (Mountain Standard Time) but Arizona does not follow any DST whereas Denver does follow it.

It’s always good to have knowledge of the challenges that one is going to face while accomplishing a task. So now we have adequate knowledge of time zone plus DST and a challenge to implement it technically.

Will soon be coming up with the technical implementation of the Time zone concepts.



One thought on “ALL ABOUT TIMEZONE: PART 1

Leave a Reply

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

You are commenting using your 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