Few things you need to know about Timezone
A time zone is a region that observes a uniform standard time for legal, commercial, and social purposes.
- Wikipedia
Earth rotates 360 degrees on its axis in 24 hours. Every 15 longitudinal degrees, the time changes by an hour, thus creating 24 time zones around the world. Over the years, governments have adopted, altered or ignored Greenwich Mean Time (GMT) as they saw fit. So right now this is what the time zone on earth looks like.
Large countries like USA, Russia, Canada have multiple time zone, hence, places situated at the opposite end of the country have a difference in time.
How many time zone a country follows, is completely a choice of the country. For example, China uses a single time zone and same goes for India.
History of timekeeping
Before the existence of standard time, people kept time using different instruments like the position of the Sun, water clock, candle clock etc. First mechanical clock was developed around 1300. Further enhancements came in the 15th century, when spring-based clock was developed, though this also introduced new challenges and spring-based clocks were improved over time. First pendulum-based clock came into existence in the 17th century. To help navigation first marine chronometer was developed in the 18th century.
How did time zone came into existence
With improvement in time keeping devices and mode of transportation, it became increasingly important to coordinate time between places, as it was getting confusing for passengers and people responsible for managing such services. For example, American railroads maintained many different time zones. Each train station sets its own click making it difficult to coordinate train schedules and confusing passengers. The same issues were faced by people travelling across the sea or ocean.
To solve this One prime meridian was proposed i.e. the Greenwich Meridian. The international 24-hour time-zone system grew from this, in which all zones referred back to GMT on the prime meridian. Interestingly not all countries followed GMT as standard. Many nations today use standard time zones i.e. one-hour deviation but some places adopt half-hour deviations from standard time or use quarter hour deviations.
Time zone ready application
Every application needs to maintain some, date related information. Date might be stored to maintain time of creation or modification of data, Date might be stored to represent a future or past event, Date might be stored to maintain information about time when a transaction occurred and many more use cases.
Lets discuss one of the many possible ways, you can do a basic setup to make your dates timezone ready.
Transfer date to server
Lets assume, your application uses HTTP protocol to communicate between client and server. Its possible that your application run on different platforms like browser, mobile application( Android, iOS, Windows). Therefore a standard format should be used to send date to server.
Date can be transferred in ISO8601 or any format you feel is correct. For example, 22nd Feb 2016, can be transferred in the format 22/02/2016 and time can be transferred in 24 hour format i.e. 2:10:42 PM will be denoted as 14:10:42.
Handling date on server
Since there’s a standard format in which date is sent to server. Server can receive the date which will be a string, and convert it into a date object. Moment.js is one such library, and can be used to convert date from string to a Moment object, from which you can easily get JS Date object.
If your application need to support timezone in multiple countries, user can be asked for UTC offset and store this information in database.
For example, While creating a new record, user can specify “some date” for new record. This user input does not contain information about the timezone, as that information is already available in database. So, whenever user creates a new record, a moment is created from date string and then UTC offset is applied to it.
Storing data in Database
You can store date in your database with time zone offset or in UTC format. Not all databases support storing time zone information along with date. So for such databases that support only UTC date, you need to convert it into the UTC string and pass it on to database.
Lifecycle of Date from client to data storage
Assumptions for the example
- Time zone on the machine is “+0000”
- Format of date string will be “DD/MM/YYYY Z”
- UTC offset specified by user is “+0530”
Various state of date string
- Date string “14/03/2016”
- Generate a moment instance :
moment( ‘14/03/2016 +0530’, ’DD/MM/YYYY Z’ )
By default, moment parses and displays in local time. Therefore offset should be specified. - Set the UTC offset
moment( ‘14/03/2016’, ’DD/MM/YYYY’ ).utcOffset( “+0530” )
this is done to ensure, if you fetch date or time value from the date object, it return the value, as per the time zone of user and not as per local machine time - Get JS date object from moment instance, whose value will be:
Sun Mar 13 2016 18:30:00 GMT+0000 (GMT)
If you look closely, the date has shifted from 14th March to 13th March and time is 18:30:00 - Convert the date into ISO format and as per UTC time zone:
2016–02–13 18:30:00
Fetching date from database
Until now we discussed how date was sent to server in string format, converted to a Date object using moment and stored into database. Now we’ll retrieve the date from database
Formatting date stored in database
- To convert date into correct timezone, UTC offset should be added. This can be done using Moment library:
moment.utc( dateStringFromDB, dateFormat ).utcOffset( utcOffset ) - Use the moment to get date value i.e. format(), getDay() etc. If you call toDate() on moment in this step, the date will again be converted to the timezone of the remote machine and information about the UTC offset set by user will be lost and the date-time values might be different then what’s expected.
Is our application ready to handle all time zone variations??
The answer is.. not really!
What did we miss?
There is another very important aspect of time zone, that we did not discuss yet and it is know as the Daylight Saving Time(DST).
Daylight saving time (DST) or summer time is the practice of advancing clocks during summer months by one hour so that in the evening daylight is experienced an hour longer, while sacrificing normal sunrise times. Typically, regions with summer time adjust clocks forward one hour close to the start of spring and adjust them backward in the autumn to standard time.
What is wrong with previous approach?
In the previous approach we used UTC offset to specify the time zone for a given region. In theory, it works fine. But with DST in picture, now we now that in many regions of the world the offset is not fixed. Its value changes by 1 hour.
So when we pass offset value eg. +0530, -0800 etc. we are ignoring the changes in UTC offset, that will come due to DST.
Use time zone name instead
Each country along with UTC offset is also assigned zone name, which are directly mapped to the UTC offset of that country. For example, for India UTC offset+0530 is associated to zone name “Asia/Kolkata”.
Zone name “US/Alaska” maps to UTC offset of “-09:00”, but during DST period it maps to “-08:00”, a difference of 1 hour.
Another reason to use zone names instead of UTC offset is, usage of DST is not followed uniformly by all the countries. Any country or state(s) with in any country might decide not to follow DST and it has happened in past. Countries have even changed the UTC offset in the past.
The Internet Assigned Numbers Authority (IANA) maintains the database for time zone across the globe and every quarter releases an updated database for time zone. Some previous releases of time zone database can be found here.
Using time zone name
In the previous section, we discussed how we can benefit by using time zone name instead of UTC offset. Moment.js have another library that is specifically maintained for time zone and its called Moment-timezone.js.
Some of the sample timezone names are:
and list goes on. There are over 500 time zone names. Some of them exist in the list for compatibility reasons.
Making zone name, user friendly
The zone names from IANA database are not necessarily user friendly and since, the list is so long, it becomes absolutely important that you make the zone names user-friendly.
One thing that we cannot do is, change the zone name in IANA time zone database. Instead we can maintain a mapping with selected time zones and each mapping can have support for selected time zones and allow you to customise the name of time zone, that user sees. Below is one such list:
For example, instead of showing “Asia/Kolkata” you can display “India(IST)”, since entire country follows single time zone. You can even change the name to any string, that is more familiar to your users. All you need to make sure is, you pass the real time zone name to the library and not the custom name.
References :
