Why does javascript has a little or no support for timezones?

Question

I was looking for something in javascript which could support time zones. My motive was:

1. Seamless conversions between two time zones.
2. Construct Date objects with distinct time zones from milliseconds.
3. Formatting Dates according to different zones and locales.

Currently I am achieving #1 by constructing back a new Date object from locale String as:

new Date(dateInSomeTimeZone.toLocaleString('en-US', {timeZone: 'Asia/Calcutta'})

This again is bad because the millis representation of this Date is different from that of the original. Also there are ways for achieving #3, but #2 appears to be a 'Not achievable'.

Is there any reason why a mature language like JS doesn't provide this feature which is supported by most of the frameworks? I know there are libraries like Moment.js doing these things, but integrating a new library is not always possible in already running applications.

If there are solutions to the points mentioned above?

Answer 1

The main problem you're running into is that JavaScript is a client-side scripting language. That means that JavaScript only uses the time the computer thinks is correct. Slight differences to these time stamps occur because the computer isn't always synced perfectly with the real time.

Support for time zones is very minimal because you can not always trust the settings for time zones on the different computers.

Besides from the reasons why, the solution you already have at the moment is the one I would suggest to use. Execution time of that code might be a problem but I think that adding a library for this would take even longer.

Answer 2

I agree that JavaScript's native date and time APIs are far from ideal, and moment.js is probably the best answer right now for most folks.

However, there are some things that are improving, as part of the ECMAScript Internationalization API (ECMA-402). Parts of the 1st edition are already implemented in some browsers, and the current 2nd edition will hopefully be rolled out over time.

The example you gave in the question, using toLocaleString is covered by this API. However, time zone support is lacking in many implementations. For example you showed using a time zone ID, which will work on Chrome but not on Internet Explorer.

Additionally, ECMA-402 is focused on your third scenario. The other two would require much more changes than are currently proposed.

As to why , consider that much of the JavaScript Date object is similar in design to the original java.util.Date from Java's JDK 1.0. When JDK 1.1 came around, much of that API was deprecated and moved to java.util.Calendar . When you compare the two Java APIs to the JavaScript Date object with ECMA-402 applied, you'll see they are very similar.

Now consider that Java developers still had lots of problems with both Date and Calendar objects, and from that frustration grew the Joda-Time library. Then eventually, those concepts were adopted and improved on in Java 8's java.time package . That is a very mature and well-thought-out API, and probably they type of thing you were looking for in JavaScript. One can only hope that it won't take the 17 years it took Java to evolve.

AFAIK, there are no drastic date/time improvements of this sort in ES6/2015, or planned for ES7/2016. So in the meantime, it will come down to libraries. moment is a good one. There are other good ones, and plenty of bad, and I'm sure there will be more of both in the future.