Solution for handling date and time for international applications
We have worked on some international applications in which we need to show meeting booking time, task time, project time, working shift time, leave time etc.. to end users who might be presented in many different places in the world. The obvious challenge here for is how to handle input start and end time for our data models and display them correctly regardless of where and where the end users be in the world.
Users in different places in the world view one point in time differently because they are in different time zones. Each time zone has a name and a time offset like +05:00 or -03:00, which indicate how many hours or minutes it differs from the UTC (Coordinated Universal Time). For example our team is in Hanoi and has UTC +07:00 time offset, and if it is 08:00 AM for us, then it would show to a person in another time zone who has offset UTC +02:00 as 03:00 AM of the same day.
It gets more complicated when some time zones have day light saving (DST), some do not. A time zone that has DST, e.g "Europe/Stockholm" , will have offset +02:00 time from 28th Mar to 31 Oct when DST is off, but will have offset +01:00 from 1st Nov when DST is on.
So if we sit in Hanoi, and create a booking for a meeting that starts on 3:00 PM time on 4th Nov with a Swedish client in Stockholm, that booking should show as starting on 09:00 AM. How to solve this in programming ?
There might be many solutions to this problem, but we often must allow a user A create a booking in his current timezone, save this booking time in our database, when sending this booking to other user B in another time zone, we have to translate this booking time to that time zone properly.
- Solution 1: system front end code submit the booking time by sending local time time and time zone info (name or offset) of user A to server, server back end code parse this date time and save to database. When user B request booking time from server, he send his local time zone (name or offset) to server, server do the time translation on server and send user B booking data in his local time. This solution has few disadvantages: putting time translation logic on server back end code consume a bit of server power unnecessary thus don't scale well, saving user A time zone info (name or offset) in database for each booking object is complicated (DateTime column type of some databases like MySQL cannot store time zone info). It also a bit involved to send user B's time zone with every request to server.
- Solution 2: system front end code convert local booking time of user A into UTC time (a UTC time string, or timestamp), server back end code save this into database, and send this UTC time to user B, front end code on user B convert this UTC time to his local time. This solution according to our experience is the best, our recommended solution.
There is another thing to be careful in Solution 2, when we send a UTC time string to server, the back end code often convert this UTC time string into a local time DateTime object in memory (according to server's time zone), and later save this local server time into database. Then another server in another time zone connected to same database could get wrong value. So it's best to have all servers and even database servers running in UTC time zone.
Sending timestamp (in milliseconds) to the server might not be that convenient because we have to convert that into a DateTime object in memory for calculation, and saving timestamp in database sometimes not the best, e.g MySQL timestamp column doesn't support millisecond.
In conclusion, solution 2 is the best solution, and when sending time to server, UTC time string conformed to ISO 8601 is the best. If you want to play around with converting a time into multiple time zones, Moment-timezone is a great library. We have a play ground here, please check it out.
