Get client timezone (not GMT offset amount) in JS [duplicate]

Question

I need to determine the client timezone (e.g. CET, GMT, EST) in JS. Getting the offset is straightforward, but doesn't have all the info necessary to determine the TZ, at least not easily. I have a feeling it might be possible to use a combination of offset, whether DST is in use and in effect, etc. but I'm hoping someone else has done the work already, especially considering the weird exceptions when dealing with time.

This question is similar but both the question and the answer are based on the (incorrect) assumption every browser's DateString format includes the name of the timezone - which it does not. That is an implementation detail.

So, with that I am currently stuck.

Answer 1

You could scrape it from a date object's toString() method. new Date.toString() results in something like Wed Sep 19 2012 10:04:32 GMT-0400 (Eastern Daylight Time) in Firefox, Safari and Chrome. The data you want is there -- the capital letters within the parentheses. All that's needed is to scrape them.

In the case of Internet Explorer, the result of toString() already includes the EDT.

In the case of Opera, your only option is to settle for GMT-0400 or similar. There's nothing scrape-able in the toString() method.

var now = new Date().toString();
var TZ = now.indexOf('(') > -1 ?
now.match(/\([^\)]+\)/)[0].match(/[A-Z]/g).join('') :
now.match(/[A-Z]{3,4}/)[0];
if (TZ == "GMT" && /(GMT\W*\d{4})/.test(now)) TZ = RegExp.$1;

Example results:

• Firefox: TZ = "EDT"

• Safari: TZ = "EDT"

• Chrome: TZ = "EDT"

• IE: TZ = "EDT"

• Opera: TZ = "GMT-0400"

Seems to work just as well with all the random Asian and European time zones I tried as well, returning WPST for Guam (West Pacific Standard Time), MPST for Kuala Lumpur (Malay Peninsula Standard Time), etc; and degrades peacefully to GMT+0X00 notation where the browser doesn't supply the name (Perth, for example).

Answer 2

See this question. It's not doable in the general case, but for picking a default timezone from a shortlist of likely cases, you can make a decent guess.

Allow the user to override it for when you guess wrong.

Answer 3

What I would do is determining the standard and daylight offset (which sounds like you already knew. If not, you can start with this reference http://onlineaspect.com/examples/timezone/detect_timezone.js by Josh Fraser). Determining the time zone can always be done on the server side once the standard and daylight offsets are known. A Ajax call can then be used so that no page refresh is ever needed. End result is you now have the time zone on the JavaScript side.