Since the data has been changed, you can’t use methods such as getTime() or getISOString().
Therefore, you must revert the conversion before sending it back to the server.
const time = ny.
getTime() + (840 * 60 * 1000); // 1489631400000Some of you may wonder why I added using the converted data when I have to convert it back anyway before returning.
It looks like I can just process it without conversion and temporarily create a converted Date object only when I’m formatting.
However, it is not what it seems.
If you change the date of a Date object based on Seoul time from 11th to 15th, 4 days are added (24 * 4 * 60 * 60 * 1000).
However, in New York local time, as the date has been changed from 10th to 15th, resultantly 5 days have been added (24* 5 * 60 * 60 * 1000).
This means that you must calculate dates based on the local offset to get the precise result.
The problem doesn’t stop here.
There is another problem waiting where you won’t get wanted value by simply adding or subtracting offsets.
Since Mar 12 is the starting date of DST in New York’s local time, the offset of Mar 15, 2017 should be -04:00 not -05:00.
So when you revert the conversion, you should add 780 minutes, which is 60 minutes less than before.
const time = ny.
getTime() + (780 * 60 * 1000); // 1489627800000On the contrary, if the user’s local time zone is New York and wants to know the time in Seoul, DST is applied unnecessarily, causing another problem.
Simply put, you can’t use the obtained offset alone to perform the precise operations based on the time zone of your choice.
If you recollect what we have discussed in the earlier part of this document, you would easily know that there is still a hole in this conversion if you know the summer time rules.
To get the exact value, you need a database that contains the entire history of offset changes, such as IANA timezone Database.
To solve this problem, one must store the entire time zone database and whenever date or time data is retrieved from the Date object, find the date and the corresponding offset, and then convert the value using the process above.
In theory, this is possible.
But in reality, this takes too much effort and testing the converted data’s integrity will also be tough.
But don’t get disappointed yet.
Until now, we discussed some problems of JavaScript and how to solve them.
Now we’re ready to use a well built library.
Moment TimezoneMoment is a well established JavaScript library that is almost the standard for processing date.
Providing a variety of date and formatting APIs, it is recognized by so many users recently as stable and reliable.
And there is Moment Timezone, an extension module, that solves all the problems discussed above.
This extension module contains the data of IANA Time Zone Database to accurately calculate offsets, and provides a variety of APIs that can be used to change and format time zone.
In this article, I won’t discuss how to use library or the structure of library in details.
I will just show you how simple it is to solve the problems I’ve discussed earlier.
If anyone is interested, see Moment Timezone’s Document.
Let’s solve the problem shown in the picture by using Moment Timezone.
const seoul = moment(1489199400000).
tz('Asia/Seoul');const ny = moment(1489199400000).
tz('America/New_York');seoul.
format(); // 2017-03-11T11:30:00+09:00ny.
format(); // 2017-03-10T21:30:00-05:00seoul.
date(15).
format(); // 2017-03-15T11:30:00+09:00ny.
date(15).
format(); // 2017-03-15T21:30:00-04:00If you see the result, the offset of seoul stays the same while the offset of ny has been changed from -05:00 to -04:00.
And if you use the format() function, you can get a string in the ISO-8601 format that accurately applied the offset.
You will see how simple it is compared to what I explained earlier.
ConclusionSo far, we’ve discussed the time zone APIs supported by JavaScript and their issues.
If you don’t need to manually change your local time zone, you can implement the necessary features even with basic APIs provided that you’re using Internet Explorer 9 or higher.
However, if you need to manually change the local time zone, things get very complicated.
In a region where there is no summer time and time zone policy hardly changes, you can partially implement it using getTimezoneOffset() to convert the data.
But if you want full time zone support, do not implement it from scratch.
Rather use a library like Moment Timezone.
I tried to implement time zone myself, but I failed, which is not so surprising.
The conclusion here after multiple failures is that it is better to “use a library.
” When I first began writing this article, I didn’t know what conclusion I was going to write about, but here we go.
As a conclusion, I would say that it’s not a recommended approach to blindly use external libraries without knowing what features they support in JavaScript and what kind of issues they have.
As always, it’s important to choose the right tool for your own situation.
I hope this article helped you in determining the right decision of your own.
ReferencesPluralsight : Date and Time FundamentalsWikipedia : timezoneWikipedia : DSTWikipedia : Unix TimeWikipedia : ISO-8601IANA timezone DatabaseMicrosoft Daylight Saving Time & Time Zone BlogMDN : Date APIjava.
util.
Date APIMoment TimezoneRFC-1123RFC2888TOAST UI :: Make Your Web Delicious!The TOAST UI Is Free Open-source JavaScript UI Libraries Maintained By NHN Entertainment.
ui.
toast.
comOriginally posted at Toast Meetup(1, 2) written by DongWoo Kim.
.