Getting the client's time zone (and offset) in JavaScript

Question

How can I gather the visitor's time zone information?

I need both:

1. the time zone (for example, Europe/London)
2. and the offset from UTC or GMT (for example, UTC+01)

Truscott

I'm figting the same problem now. Here is an interesting approach. – Ampliate

I need the timezone. The GMT offset would be helpful too. – Abbyabbye

The answers here focus mostly on offset. For time zone see this answer. See "Time Zone != Offset" in the timezone tag wiki. – Buhler

You get exact Timezone by using this Intl.DateTimeFormat().resolvedOptions().timeZone – Castellano

subquestion: JS relies on the host system settings developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/… – Corron

@citykid I've edited the question title to make it clearer. – Nosedive

Note that #2 depends on the time of the year. And it's not like "PDT"/"CET". If you need to know more about the difference between them, read my answer below: stackoverflow.com/a/69961228 – Frayda

Answer 1

Using getTimezoneOffset()

You can get the time zone offset in minutes like this:

var offset = new Date().getTimezoneOffset();
console.log(offset);
// if offset equals -60 then the time zone offset is UTC+01

The time-zone offset is the difference, in minutes, between UTC and local time. Note that this means that the offset is positive if the local timezone is behind UTC and negative if it is ahead. For example, if your time zone is UTC+10 (Australian Eastern Standard Time), -600 will be returned. Daylight savings time prevents this value from being a constant even for a given locale

• Mozilla Date Object reference

Note that not all timezones are offset by whole hours: for example, Newfoundland is UTC minus 3h 30m (leaving Daylight Saving Time out of the equation).

Please also note that this only gives you the time zone offset (eg: UTC+01), it does not give you the time zone (eg: Europe/London).

Balladist

@abernier Is the statement about getTimezoneOffset inaccuracy in effect? The article you are referring to is dated of June 2007 and has no details of how the function is inaccurate. And in fact the library jsTimezoneDetect you pointed uses getTimezoneOffset itself. – Kathrynekathy

@abernier It's a standard since ES 1, so I'm sure any implementation problem might be fixed by now, I mean, that is a 7 years old article. – Imperturbable

Everything is fine with 'Date.getTimezoneOffset()' function, however to determine correct timezone name, based only on offset, you may need 'jsTimezoneDetect' library. – Medullary

var hrs = -(new Date().getTimezoneOffset() / 60) to get offset in hours typically used – Mahmoud

Seems it does not consider daylight saving time – Risotto

@MohammedShareefC Read the doc carefully, difference between UTC and local time. UTC = 12:00, Local = 12:00 + 5:30 = 17:30, so difference is 12:00 - 17:30 = -5:30 – Endocarditis

timezone != utc offset – Antilogarithm

Intl.DateTimeFormat().resolvedOptions().timeZone will give the timezone of cient. – Fumigant

I have been testing this, "new Date().getTimezoneOffset()", while working on this problem. At least on Windows 10 and with Edge, it sends me the correct offset, taking into account the timezone's DST settings, as I change the timezone. The only consideration is that I have to restart Edge between system timezone changes (and when changing the timezone, I have to select "Adjust for daylight savings time automatically"). It is worth noting that quite a few timezones share offsets, but as long as the only thing you care about is converting to and back from UTC, this works great. – Dukas

var hrs = new Date().getTimezoneOffset() / -60; // less parenthesis – Rosina

@Risotto Not sure what you mean. According to the answer https://mcmap.net/q/21147/-how-to-check-if-dst-daylight-saving-time-is-in-effect-and-if-so-the-offset here, running this function in the summer and in the winter in a place where DST is in effect should give you different results? – Protamine

"getTimezoneOffset()" does take into account Daylight Saving Time, because as it says in the link provided in the answer: "...the return value may change based on the time of the year date is in." developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/… – Viscometer

Answer 2

Using an offset to calculate Timezone is a wrong approach, and you will always encounter problems. Time zones and daylight saving rules may change on several occasions during a year, and It's difficult to keep up with changes.

To get the system's IANA timezone in JavaScript, you should use

console.log(Intl.DateTimeFormat().resolvedOptions().timeZone)

As of April 2023, this works in 95.42% of the browsers used globally.

Old compatibility information

ecma-402/1.0 says that timeZone may be undefined if not provided to constructor. However, future draft (3.0) fixed that issue by changing to system default timezone.

In this version of the ECMAScript Internationalization API, the timeZone property will remain undefined if no timeZone property was provided in the options object provided to the Intl.DateTimeFormat constructor. However, applications should not rely on this, as future versions may return a String value identifying the host environment’s current time zone instead.

in ecma-402/3.0 which is still in a draft it changed to

In this version of the ECMAScript 2015 Internationalization API, the timeZone property will be the name of the default time zone if no timeZone property was provided in the options object provided to the Intl.DateTimeFormat constructor. The previous version left the timeZone property undefined in this case.

Ehlers

moment.js makes use of it where supported. Otherwise falls back to getTimezoneOffset(). – Genus

It took me a while to find the list of time zones returned by this API. Here it is: en.wikipedia.org/wiki/List_of_tz_database_time_zones – Traceytrachea

In Edge it return "Asia/Kolkata" and in Chrome return "Asia/Calcutta" for india. Causing issue for me on server side to convert in UTC – Bethlehem

This also works nice with selecting the same list generated by PHP: php.net/manual/en/function.timezone-identifiers-list.php – Octennial

If you want the abbreviation instead, use this: stackoverflow.com/questions/1954397/… – Brunildabruning

What if I take my device abroad? Will it provide the correct time zone while I travel? My concern is if I convert date to this timezone provided by the API and show it to the user, is this always okay? – Coulee

@XavierPoinas it's accessible from the Intl object Intl.supportedValuesOf('timeZone') ! (then you can use locale "ia" to get the offset) – Hamitosemitic

OP asked for offset as wellm, and you recommended not using it, this tells how to get local IANA timezone (awesome), struggling to understand what to do with this in terms of converting or relating from another time locale (say for scheduling) without an offset to UTC how can this be utilized? – Crush

@GreggoryWiley You need both. I think what the original poster is saying, is to not rely on just offset to calculate a timezone. Use both independently for their intended use case. – Coycoyle

Answer 3

Edit 3-19-2022 - WARNING: I no longer recommend this approach as it has issues with multiple browsers and locales.

I realize this answer is a bit off topic but I imagine many of us looking for an answer also wanted to format the time zone for display and perhaps get the zone abbreviation too. So here it goes...

If you want the client timezone nicely formatted you can rely on the JavaScript Date.toString method and do:

var split = new Date().toString().split(" ");
var timeZoneFormatted = split[split.length - 2] + " " + split[split.length - 1];

This will give you "GMT-0400 (EST)" for example, including the timezone minutes when applicable.

Alternatively, with regex you can extract any desired part:

For "GMT-0400 (EDT)" :

new Date().toString().match(/([A-Z]+[\+-][0-9]+.*)/)[1]

For "GMT-0400" :

new Date().toString().match(/([A-Z]+[\+-][0-9]+)/)[1]

For just "EDT" :

new Date().toString().match(/\(([A-Za-z\s].*)\)/)[1]

For just "-0400":

new Date().toString().match(/([-\+][0-9]+)\s/)[1]

Date.toString reference: https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Date/toString

EDIT 10/6/2020 - The above solution may not work in all browsers and locales. If possible in your scenario, I would recommend utilizing a javascript library like date-fns, luxon or dayjs which provide timezone support.

Embark

Broken with Chrome as it appends the name of the timezone. Do not use split.length but a constant instead split[4] + " " + split[5] ?! – Starnes

This also doesn't work in (surprise, surprise) IE. I just did a console dump of the split Date object. It's the same in Chrome, Firefox and Safari, but different in IE. So, you can't count on the constant indexes either. Mon Dec 02 2013 10:22:50 GMT-0500 (EST) : Chrome, FF, Safari; Mon Dec 2 10:22:50 EST 2013 : IE10 – Impenetrable

I found this answer to work better cross-browser (IE 9 etc.): https://mcmap.net/q/21166/-get-client-timezone-not-gmt-offset-amount-in-js-duplicate. – Merthiolate

Gosh thank you! I have been jumping through hoops trying to display browser timezone..... ew Date().toString().match(/([A-Z]+[\+-][0-9]+.*)/)[1] was exactly what I needed! – Unbrace

I wound up with: var fullTz = new Date().toString().match(/\(([A-Za-z\s].*)\)/)[1]; var parts = fullTz.split(' '); var tz = ""; parts.forEach(function (element, index, array) { tz += element.substring(0, 1); }); yields: "EST", for example – Manilla

A timezone is not an offset (but has an offset), so the accepted answer is wron. How do I get the full timezone name, like Europe/Helsinki? related: https://mcmap.net/q/21167/-get-name-of-time-zone – Dovev

This doesn't work. For me split contains: ["Mon", "Mar", "13", "2017", "14:05:22", "GMT-0400", "(Eastern", "Daylight", "Time)"] so the result is Daylight Time) – Pincas

This method recently broke for me. I suspect it happened due to OS X 10.12.4 Update. It's broken for all South American timezones in all browsers. For Sao Paulo, "new Date().toString()" now returns: FF GMT-0300, Chrome GMT-0300 (-03), Safari GMT-0300 (-03). – County

This is actually not a good idea the actual representation of the JS time after you do new Date().toString() is completely dependant on your locale settings. Expecting other clients' outputs to resemble yours is a very bad idea. – Dufy

Using Date.toString() is not reliable, and MDN explains why. I've pasted the relevant section from their docs in my answer. – Reseat

1) it only works on en-us, and not even in the UK! 2) it gives back (PDT/CEST) which is NOT year-round valuable! Read my detailed answer: stackoverflow.com/a/69961228 – Frayda

This answer is wrong on many levels. It only works for 1/20th of the world's population and only if the locale is set to en-us. Meaning it does not work if you have a Spanish language locale when living in the US, for instance. Also relying on locale dependant, non-standarized output is just a bad idea to begin with. Use the Intl library. – Achromic

As of Nov 2023 chrome does this (us-en): new Date().toString().match(/\(([A-Za-z\s].*)\)/)[1] -> 'Pacific Standard Time' – X

Answer 4

I wrote a function in my project, which returns the timezone in hh:mm format. I hope this may help someone:

function getTimeZone() {
    var offset = new Date().getTimezoneOffset(), o = Math.abs(offset);
    return (offset < 0 ? "+" : "-") + ("00" + Math.floor(o / 60)).slice(-2) + ":" + ("00" + (o % 60)).slice(-2);
}

---

// Outputs: +5:00

function getTimeZone() {
  var offset = new Date().getTimezoneOffset(), o = Math.abs(offset);
  return (offset < 0 ? "+" : "-") + ("00" + Math.floor(o / 60)).slice(-2) + ":" + ("00" + (o % 60)).slice(-2);
}


// See output
document.write(getTimeZone());

Working Fiddle

Code with comments

/**
 * Get client side timezone.
 *
 * @returns {(+|-)HH:mm} - Where `HH` is 2 digits hours and `mm` 2 digits minutes.
 * @example
 * // From Indian/Reunion with UTC+4
 * // '+04:00'
 * getTimeZone()
 */
const getTimeZone = () => {
  const timezoneOffset = new Date().getTimezoneOffset()
  const offset = Math.abs(timezoneOffset)
  const offsetOperator = timezoneOffset < 0 ? '+' : '-'
  const offsetHours = Math.floor(offset / 60).toString().padStart(2, '0')
  const offsetMinutes = Math.floor(offset % 60).toString().padStart(2, '0')

  return `${offsetOperator}${offsetHours}:${offsetMinutes}`
}

Rhearheba

This returns the time zone offset (eg: UTC+01), it does not return the time zone (eg: Europe/London) – Nosedive

@Nosedive better to use the moment and moment-timezone library for that. We can't have that in two lines code. – Rhearheba

There is an issue for indian timezone: +05:30 as the (offset / 60) and (offset % 60) didn't consider floats... const offsetHours = Math.floor(offset / 60).toString().padStart(2, '0'); and `const offsetMinutes = Math.floor(offset % 60).toString().padStart(2, '0');' – Nighttime

Thanks @AdrianSanchez. fixed it. It actually worked in min code but not the commented code. – Rhearheba

Answer 5

It's already been answered how to get offset in minutes as an integer, but in case anyone wants the local GMT offset as a string e.g. "+1130":

function pad(number, length){
    var str = "" + number
    while (str.length < length) {
        str = '0'+str
    }
    return str
}

var offset = new Date().getTimezoneOffset()
offset = ((offset<0? '+':'-')+ // Note the reversed sign!
          pad(parseInt(Math.abs(offset/60)), 2)+
          pad(Math.abs(offset%60), 2))

Mosstrooper

You need to replace 1st padding with pad(parseInt(Math.abs(offset/60)), 2) to get it right... else you might end up getting +5.530 as in my case... i m not sure if math floor etc will be a better thing here or not.... but this atleast gives me +0530 as expected – Weeks

this will give correct result: this.pad(Math.floor((Math.abs(offset/60))), 2) – Passage

Instead of using your pad function, I find it easier to do this: offset = (offset<0 ? "+" : "-") + ("0000" + parseInt((Math.abs(offset/60)))).slice(-4) – Glasses

replace parseInt(...) with (...)|0 or Math.floor(...). Why would you convert it to a string and then back to an number? – Quattlebaum

Answer 6

You can use:

moment-timezone

<script src="moment.js"></script>
<script src="moment-timezone-with-data.js"></script>

// retrieve timezone by name (i.e. "America/Chicago")
moment.tz.guess();

Browser time zone detection is rather tricky to get right, as there is little information provided by the browser.

Moment Timezone uses Date.getTimezoneOffset() and Date.toString() on a handful of moments around the current year to gather as much information about the browser environment as possible. It then compares that information with all the time zone data loaded and returns the closest match. In case of ties, the time zone with the city with largest population is returned.

console.log(moment.tz.guess()); // America/Chicago

Lisettelisha

This should be the accepted answer. This is the only one that gives the actual timezone name rather than offset. Remember that timezone offset can be derived from the name, the opposite isn't true. Because of DST and other subtleties, multiple timezones can have the same offset on some specific days of the year only. – Fear

There's a native solution for this now - the Intl API. While moment.js was a great library back in the day, there are far smaller alternatives currently (dayjs, date-fns). Moment is huge; please do not recommend it for client applications. – Reseat

@Romain G Except he asked about the offset specifically... I don't understand why everyone here is obsessed with getting the name. What are you going to do with that? The most useful scenario for knowing the timezone is to format a UTC date to the local browser for the UI. – Rhpositive

Answer 7

A one-liner that gives both the offset and the time zone is to simply call toTimeString() on a new Date object. From MDN:

The toTimeString() method returns the time portion of a Date object in human readable form in American English.

The catch is that the timezone is not in the standard IANA format; it's somewhat more user-friendly, than the "continent/city" IANA format. Try it out:

console.log(new Date().toTimeString().slice(9));
console.log(Intl.DateTimeFormat().resolvedOptions().timeZone);
console.log(new Date().getTimezoneOffset() / -60);

In California right now, toTimeString() returns Pacific Daylight Time while the Intl API returns America/Los_Angeles. In Colombia, you'd get Colombia Standard Time, vs. America/Bogota.

Note that many other answers to this question attempt to obtain the same information by calling Date.toString(). That approach is not that reliable, as MDN explains:

Date instances refer to a specific point in time. Calling toString() will return the date formatted in a human readable form in American English. [...] Sometimes it is desirable to obtain a string of the time portion; such a thing can be accomplished with the toTimeString() method.

The toTimeString() method is especially useful because compliant engines implementing ECMA-262 may differ in the string obtained from toString() for Date objects, as the format is implementation-dependent; simple string slicing approaches may not produce consistent results across multiple engines.

Reseat

"In California right now, toTimeString() returns Pacific Daylight Time" that depends on whether you run your code in summer or winter! Read my even-more-detailed answer about why PDT is probably not the value you are looking for: stackoverflow.com/a/69961228 – Frayda

Those are named time offsets, not timezones. The IANA ones are timezone. A city is always in the same time zone (unless the IANA tables update), but it usually has different offsets from UTC during a year due to summer/winter changes. – Achromic

Answer 8

This question already has 30+ answers, but I am sure there are people who will come here and really don't know what they are looking for.

Surprise! you are about to open a can of worms!

I strongly recommend reading this article that I wrote recently about the headaches of dealing with TimeZones in JS! https://medium.com/@EyeDin/time-and-time-zone-headaches-in-javascript-ae4d873a665d

What are you EXACTLY looking for?

Depending on your actually use case, you actually need different things.

---

1) A way to convert a fixed point-in-time (like November 13th of 2021 at 11:35:21pm in San Francisco) to the user's wall-clock time, who might be anywhere in the world.

Use .toLocaleString().

It has more customization parameters for formatting than you can think of, via its two parameters of locale and options listed at DateTimeFormat. It even supports different calendars, languages, ways of formatting year, month, day, etc. (no passed parameter will use the user's default settings, which might be the ideal.)

As a developer, just pass that point-in-time value (e.g. opening time of a Sales event, or a competition) as UNIX timestamp number (that's the number of seconds from 1/1/1970 in UTC, timezone-agnostic and DST0agnostic) to the client, and then do new Date(timestamp).toLocaleString(). e.g. for that point-of-time above, the value is 1636875321000 (in milliseconds), via +dateWithTimeZone("America/Los_Angeles",2021,10,13,23,35,21) using the function from this answer.

---

2) Be able to send the user a notification/email at 9am of their local time, 3 months from now

This is a totally different requirement! Like, very very different!

Isn't GMT-8:00 enough?

No!

That's just the time zone the user is at, at one point of time, like "right now, today".

• How would you know if the user has Daylight Saving or not? (Arizona in the US doesn't, and so many other countries and states, and even counties!)
• How would you know if the user is in the DST or out of it? Is it winter in San Francisco (GMT-8) or summer in Alaska (again, GMT-8). See this giant list to freak out: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

Isn't "PDT" enough for that?

No!

First of all, PDT isn't even a year-round thing. It's November now and timeanddate.com says "No locations currently on PDT. Would you like to see PST?" (read my Medium article above for more details.)

Unless you are going for the cosmetic from-client-to-client UI string, this PDT/CEST/etc. doesn't worth anything!

Why? Because Tijuana in Mexico and San Francisco in the US are both in PDT during June, but they have different DST (Daylight Saving) days that they switch to PST. And you need to know that!

US's DST days in 2022 are Mar 13, 2022 to Nov 6, 2022. Mexico's DST days in 2022 are April 3, 2022 to Oct 30, 2022. So, while Tijuana and San Francisco are sharing that "PDT/PST" thing in almost 93% of the days, in 7% of the days (e.g. Mar 14 till April 3, and Oct 31 till Nov 6 in 2022) they don't match.

So, even if you know it's November and you know the user is in PDT, you cannot tell when (which timestamp number) would be 9am of April 1st of 2022 in the user's device.

PS. Worse if you are trying to get that PDT from new Date().toString(). FYI, if you change the locale of your machine to es-MX (Spanish, that's the language of 13% of the US population), this is what you get:

> new Date().toString()
'Sun Nov 14 2021 00:47:25 GMT-0800 (hora estándar del Pacífico)'

Good Luck with hedP!

Then, what should I do?

The ONLY CORRECT WAY is to use IANA (read "standard") Time Zone values. That's the second column of this Wikipedia page. It comes from:

const timeZoneIANA = Intl.DateTimeFormat().resolvedOptions().timeZone;

It returns the IANA value, which is America/Los_Angeles for San Francisco. This is the value you should store in your DB for the user, if anything. You can get all sorts of information about it at from timezones.json package, and convert a time from/to that timezone, plus the day (which matters) like this answer.

What about IE11?

IE11 doesn't support that Intl.... thing. Most polyfills are just guessing it and are inaccurate. So, try to drop support for IE11, or use a library and prepare yourself for some inaccuracy.

---

3) I just want to find out their time zone offset at the moment (e.g. -8:00)

You probably shouldn't. I cannot think of any real reason that you need this. Again, knowing this value for today, doesn't tell you what would this value be even tomorrow.

Anyhow, you can always get that value by

new Date().getTimezoneOffset() / 60

in client side.

NOTE: .getTimezoneOffset() is NOT the timezone offset of the date object, you are calling it on. Please read the documentation.

To be accurate, it takes the passed Date object (which has a timestamp, which refer to a single point-of-time in the history), and then tells what's the difference between the UTC time and local time at the point-of-time.

Again, it depends on the date. See:

console.log(new Date("6/13/2021").getTimezoneOffset() / 60); // It's 7 on a machine that runs in San Francisco
console.log(new Date("11/13/2021").getTimezoneOffset() / 60); // It's 8 on a machine that runs in in San Francisco

---

Any libraries?

Here is a list of libraries that support time zone exchanges.

But, remember, you have to solve the design problem first, and then look for the code. Things around time zone can easily get complicated and you have to know "PDT" and "GMT-8" are NOT year-round informative/valuable time zone values to store in the DB for the user. :)

Frayda

Answer 9

try getTimezoneOffset() of the Date object:

var curdate = new Date()
var offset = curdate.getTimezoneOffset()

This method returns time zone offset in minutes which is the difference between GMT and local time in minutes.

Melanochroi

Answer 10

JavaScript:

var d = new Date();
var n = d.getTimezoneOffset();
var timezone = n / -60;
console.log(timezone);

Stem

What does this answer provide that previous answers haven't? – Reseat

Answer 11

Try this :

new Date().toLocaleString("en-US",Intl.DateTimeFormat().resolvedOptions().timeZone)

This will look for timeZone on your client's browser.

Coquina

On Chrome 88, on OS X 11.1, this doesn't seem to return the timezone. It returns the current local date and time as a (localized) string: "2/18/2021, 11:04:34 AM" – Unriddle

Yes @JeffEvans it gets the date in string format, to get timezone just print "Intl.DateTimeFormat().resolvedOptions().timeZone". I've added the new Date part to convert it to the date string. – Coquina

The second parameter of Date.prototype.toLocaleString must be an object: developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/…. You are passing a string. Downvoted. – Frayda

Just Intl.DateTimeFormat().resolvedOptions().timeZone – Stem

Answer 12

With moment.js:

moment().format('zz');

Pox

z and zz have been deprecated as of 1.6.0 see momentjs.com/docs/#/displaying/format – Uwton

@Uwton it is now Z and ZZ – Renaud

@Renaud These parameters don't return the same thing. z and zz returned the timezone, e.g. CST, but Z and ZZ return the offset, e.g. -0600. – Cagliostro

Latest docs show .zoneAbbr() has replaced zand zz. See documentation here – Spectrograph

While moment.js was a great library back in the day, there are far smaller alternatives currently (dayjs, date-fns). Moment is huge; please do not recommend it for client applications. – Reseat

Answer 13

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat/DateTimeFormat

The Intl.DateTimeFormat() constructor creates Intl.DateTimeFormat objects that enable language-sensitive date and time formatting.

Intl.DateTimeFormat().resolvedOptions().timeZone // Asia/Kolkata

Pukka

Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center. – Ecumenical

Downvoted. It's literally one line from the top (and older) answer that has more details. I have a hard time seeing it adding any value here. – Frayda

Answer 14

With momentjs, you can find current timezone as

console.log(moment().utcOffset()); // (-240, -120, -60, 0, 60, 120, 240, etc.)

<script src="https://cdn.jsdelivr.net/momentjs/2.13.0/moment.min.js"></script>

---

With dayjs, you can find current timezone as

console.log(dayjs().utcOffset()); // (-240, -120, -60, 0, 60, 120, 240, etc.)

<script src="https://unpkg.com/[email protected]/dayjs.min.js"></script>

Both API returns utc offset in minutes.

• moment Doc
• Dayjs Doc

Jughead

While moment.js was a great library back in the day, there are far smaller alternatives currently (dayjs, date-fns). Moment is huge; please do not recommend it for client applications. – Reseat

"With dayjs, you can find current timezone as" is not exactly accurate - you'll only find the offset, not the timezone. Also, Dayjs doesn't have timezone support. Its .utcOffset() method is a simple wrapper over the native getTimezoneOffset(). – Reseat

Answer 15

as mentioned by others, to get a timezone :

const tz = Intl.DateTimeFormat().resolvedOptions().timeZone

Not mentioned before, to get the offset from the timezone, use locale "ia" (see https://mcmap.net/q/21169/-get-utc-offset-from-timezone-in-javascript)

const getOffset = (tz) => Intl.DateTimeFormat("ia", {
                timeZoneName: "shortOffset",
                timeZone : tz
              })
                .formatToParts()
                .find((i) => i.type === "timeZoneName").value // => "GMT+/-hh:mm"
                .slice(3); //=> +/-hh:mm

 console.log(tz + ' UTC' + getOffset(tz))


 

Hamitosemitic

Answer 16

Timezone in hours-

var offset = new Date().getTimezoneOffset();
if(offset<0)
    console.log( "Your timezone is- GMT+" + (offset/-60));
else
    console.log( "Your timezone is- GMT-" + offset/60);

If you want to be precise as you mentioned in comment, then you should try like this-

var offset = new Date().getTimezoneOffset();

if(offset<0)
{
    var extraZero = "";
    if(-offset%60<10)
      extraZero="0";

    console.log( "Your timezone is- GMT+" + Math.ceil(offset/-60)+":"+extraZero+(-offset%60));
}
else
{
    var extraZero = "";
    if(offset%60<10)
      extraZero="0";

    console.log( "Your timezone is- GMT-" + Math.floor(offset/60)+":"+extraZero+(offset%60));
}

Larch

Does not work for timezones when it is not a full hour, like Venezuela, where it return GMT-4.5 – Shivaree

Yes, that is right. 0.5 means 0.5*30 mins. I think you got this why it is giving 0.5? – Larch

yes, so GMT-4.5 is not a valid timezone, it needs a bit of extra parsing to become GMT-4:30 – Shivaree

@Mirko now second part of the answer is for you – Larch

If you want to be more precise, use UTC instead of GMT, [ Hilton and McCarthy 2013, p. 231–2. ], see also at wikipedia GMT - (en.wikipedia.org/wiki/Greenwich_Mean_Time) – Haldane

This returns the offset (eg: GMT+01), not the time zone (eg: Europe/London) – Nosedive

Answer 17

This might not be the most elegant solution but it is the most versatile.

This uses the timeZoneName property of Intl.DateTimeFormat

function getTimeZone(zoneName = "long") {
    // set up formatter
    let formatter = new Intl.DateTimeFormat(undefined, {
        timeZoneName: zoneName
    });
    // run formatter on current date
    return formatter.formatToParts(Date.now())
        // extract the actual value from the formatter, only reliable way i can find to do this
        .find(formatted => formatted.type === "timeZoneName")['value'];
}
// console.log every type
for (const zoneName of ['short', 'long', 'shortOffset', 'longOffset', 'shortGeneric', 'longGeneric']) {
    console.log(`${zoneName}: ${getTimeZone(zoneName)}`)
}
/*
short: CDT
long: Central Daylight Time
shortOffset: GMT-5
longOffset: GMT-05:00
shortGeneric: CT
longGeneric: Central Time
*/

This not only gets the formatted GMT offset time (i.e. GMT-5), but also the colloquial name of the timezone (i.e. Central Daylight Time)

The only thing this method doesn't do is get the IANA timezone. I recommend the top answer for that.

As far as I'm aware, DateTimeFormat doesn't have a way to do custom formatting, hence the use of formatToParts, which seems to be the only reliable way to get just the timezone.

something important to note that only short and long are officially defined in the current ECMAscript specs, the other 4 options are part of a proposal that is only somewhat standard, notably missing on safari as of writing this, though it is in progress

Sibby

It worth noting that these values are not helpful at all for the Server Side. Being on PDT doesn't determine your DST days (Tijuana in Mexico and SF in the US are both on PDT with different DST days.) As for the offset, new Date().getTimezoneOffset() / 60 would give it. – Frayda

yeah this is more for a human-readable timezone. i'd imagine people would more quickly understand "pacific time" or "GMT-5" than the specific city. I used it for a tiny webapp at reticivis.net/mytimezone – Sibby

"PDT" and America/Los_Angeles are two different things. (and IANA Time Zones are more than "city name"s). Using one for the other can be like 7% wrong! I would recommend reading my detailed answer here: stackoverflow.com/a/69961228 – Frayda

i'm aware that IANA timezones are more accurate than ones like PDT, but people might want "PDT" for whatever reason so I put the answer here because there is a way – Sibby

Answer 18

This value is from user's machine and it can be changed anytime so I think it doesn't matter, I just want to get an approximate value and then convert it to GMT in my server.

For example, I am from Taiwan and it returns "+8" for me.

Working example

JS

function timezone() {
    var offset = new Date().getTimezoneOffset();
    var minutes = Math.abs(offset);
    var hours = Math.floor(minutes / 60);
    var prefix = offset < 0 ? "+" : "-";
    return prefix+hours;
}


$('#result').html(timezone());

HTML

<div id="result"></div>

Result

+8

Edveh

Change your system's time to Nepal (it's UTC+05:45 -- en.wikipedia.org/wiki/UTC%2B05:45) and your code print's out +5. – Frayda

Answer 19

If all you need is the "MST" or the "EST" time zone abbreviation:

function getTimeZone(){
    var now = new Date().toString();
    var timeZone = now.replace(/.*[(](.*)[)].*/,'$1');//extracts the content between parenthesis
    return timeZone;
}
console.log(getTimeZone());

Batha

Using Date.toString() is not reliable, and MDN explains why. I've pasted the relevant section from their docs in my answer. – Reseat

I just changed my machine's locale to es-MX (13% of US population speak Spanish) and your code gives me hora estándar del Pacífico. Read my detailed answer about why even MST is inaccurate: stackoverflow.com/a/69961228 – Frayda

That is not the timezone. That is a name of the offset. Offset != Timezone. The timezone stays the same, the offset does not. – Achromic

Please read my answer. I clearly said "If all you need is the "MST" or the "EST" time zone abbreviation". Also this is valid only when getting client side time zone from browser with EN Lang. There are other more accurate answers and native js methods available now to get the time zone. – Dwarf

Answer 20

See this resultant operator was opposite to the Timezone .So apply some math function then validate the num less or more.

See the MDN document

var a = new Date().getTimezoneOffset();

var res = -Math.round(a/60)+':'+-(a%60);
res = res < 0 ?res : '+'+res;

console.log(res)

Makedamakefast

incase of negative value, some issue – Cattycornered

Why round? It should be floor, isn't it? – Orsay

This returns the time zone offset (eg: UTC+01), and not the time zone (eg: Europe/London) – Nosedive

I am in California and your code prints out +-8:0. – Frayda

Answer 21

function getLocalTimeZone() {
    var dd = new Date();
    var ddStr = dd.toString();
    var ddArr = ddStr.split(' ');
    var tmznSTr = ddArr[5];
    tmznSTr = tmznSTr.substring(3, tmznSTr.length);
    return tmznSTr;
}

Example : Thu Jun 21 2018 18:12:50 GMT+0530 (India Standard Time)

O/P : +0530

Henslowe

Using Date.toString() is not reliable, and MDN explains why. I've pasted the relevant section from their docs in my answer. – Reseat

Answer 22

Try this,

new Date().toString().split("GMT")[1].split(" (")[0]

Surgeonfish

Using Date.toString() is not reliable. – Nosedive

Answer 23

As an alternative to new Date().getTimezoneOffset() and moment().format('zz'), you can also use momentjs:

var offset = moment.parseZone(Date.now()).utcOffset() / 60
console.log(offset);

<script src="https://cdn.jsdelivr.net/momentjs/2.13.0/moment.min.js"></script>

jstimezone is also quite buggy and unmaintained (https://bitbucket.org/pellepim/jstimezonedetect/issues?status=new&status=open)

Renaud

While moment.js was a great library back in the day, there are far smaller alternatives currently (dayjs, date-fns). Moment is huge; please do not recommend it for client applications. – Reseat

Answer 24

On the new Date() you can get the offset, to get the timezone name you may do:

new Date().toString().replace(/(.*\((.*)\).*)/, '$2');

you get the value between () in the end of the date, that is the name of the timezone.

Hindermost

Using Date.toString() is not reliable, and MDN explains why. I've pasted the relevant section from their docs in my answer. Also, this answer has been given at least 3 times already. – Reseat

1) I changed my machine's locale to es-Mx (13% of US population speak Spanish) and your code give 'hora estándar del Pacífico'. – Frayda

Answer 25

This would be my solution:

    // For time zone:
    const timeZone = /\((.*)\)/.exec(new Date().toString())[1];
    
    // Offset hours:
    const offsetHours = new Date().getTimezoneOffset() / 60;
    
    console.log(`${timeZone}, ${offsetHours}hrs`);

Dwarf

1) I changed my machine's locale to es-Mx (13% of US population speak Spanish) and the timeZone you code gives is 'hora estándar del Pacífico'. 2) the offsetHours you are running depends on the time of the year and is not year-round reliable. 3) Did you copy this snippet from another StackOverflow answer and held the mouse button down a bit long? what's the last line? – Frayda

And this is also wrong and copy-pasted. Badly. – Achromic

Answer 26

Use this to convert OffSet to postive:

var offset = new Date().getTimezoneOffset();
console.log(offset);
this.timeOffSet = offset + (-2*offset);
console.log(this.timeOffSet);

Nightfall

x + (-2*x) === -x. – Frayda

Answer 27

Once I had this "simple" task and I used (new Date()).getTimezoneOffset() - the approach that is widely suggested here. But it turned out that the solution wasn't quite right. For some undocumented reasons in my case new Date() was returning GMT+0200 when new Date(0) was returning GMT+0300 which was right. Since then I always use

(new Date(0)).getTimezoneOffset() to get a correct timeshift.

Mussulman

This does not work if you're currently in summer time in daylight saving. new Date(0) returns jan 1st 1970, which is wintertime, while you may at your current point have +1:00 due to being in summertime – Angele

makes sense, but seems not my case: (new Date(0)).getTimezoneOffset() returns '-180' but (new Date('2021-01-01')).getTimezoneOffset() returns '-120'. Seems like browser keeps history of timezone changes for certain country. Anyway, (new Date(0)) works for me anytime – Mussulman

Well, for me, I'm currently on UTC+2 due to it still being summertime here. new Date().getTimezoneOffset() returns -120, which is correct, while new Date(0).getTimezoneOffset() returns -60 due to it being wintertime. Things to consider are if summertime in your locality was implemented the same way in 1970, but more important of all, if you're developing for clients around the globe, are you certain that their timezones were the same in 1970? If I was to use your software where I'm at I would receive the wrong timezone due to you setting it for me to 1970 wintertime. – Angele

Downvoted. The fact that you consider "GMT offset" as a year-round "time zone" indicates that you are mixing different definitions. I would encourage you to read my detailed answer at stackoverflow.com/a/69961228 – Frayda

This is wrong on so many levels. Date is correctly implemented, but you have just misunderstood what a timezone is. You mistake the offset for a timezone, but a timezone usually has (at least) 2 different offsets per year, typically due to DST. – Achromic

Answer 28

Why not just use:

function timezoneOffset(date: Date) {
  return 6000 * ((date.getUTCHours() - date.getHours()) * 60 + ((date.getUTCMinutes() - date.getMinutes())))
}

Laird

1) date.getTimezoneOffset() is a fully supported (caniuse.com/mdn-javascript_builtins_date_gettimezoneoffset), built-in function that does exactly this. 2) You should always use built-in functions, because well, here for example, you have missed an additional 0 in the first number of your code, and you haven't noticed it. I hope it's not in production somewhere. – Frayda

Answer 29

Here is the solution for finding the remote countries TimezoneOffset by just passing the timezone to the function. In this example 'Asia/Calcutta' is the timezone

function getTimezoneOffset(timezone) {
    LocalDate = new Date();
    LocalDate.setMilliseconds(0);

    const LocalOffset = LocalDate.getTimezoneOffset();
    RemoteLocaleStr = LocalDate.toLocaleString('en-US', {timeZone: timezone});
    RemoteDate = new Date(RemoteLocaleStr);
    diff = (LocalDate.getTime()-RemoteDate.getTime()) / 1000 / 60 ;

    RemoteOffset = LocalOffset + diff;
    return RemoteOffset;
}
console.log(getTimezoneOffset('Asia/Calcutta'));

Gelsemium

Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center. – Ecumenical

1) That's not an answer to this question. Your code is TimeZone -> Offset. The question here is how to get TimeZone. The relevant question to yours is https://mcmap.net/q/21122/-how-to-initialize-a-javascript-date-to-a-particular-time-zone 2) One TimeZone can have different offsets based on the time of the year -- github.com/dmfilipenko/timezones.json/blob/master/…. So your function is returning a value that's not reliable year-round. 3) it can be written as -(new Date(new Date().toLocaleString("en-us", { timeZone: "Asia/Calcutta" })) - new Date(new Date().toLocaleString("en-us", { timeZone: "UTC" }))) / 60000 – Frayda

Answer 30

You just to to include moment.js and jstz.js

<script src="https://cdnjs.cloudflare.com/ajax/libs/moment.js/2.17.1/moment.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/jstimezonedetect/1.0.6/jstz.min.js"></script>

and after that

<script>
$(function(){
 var currentTimezone = jstz.determine();
 var timezone = currentTimezone.name();
 alert(timezone);
});

</script>

Paquin

Answer 31

This is very good work for me:

// Translation to offset in Unix Timestamp
let timeZoneOffset = ((new Date().getTimezoneOffset())/60)*3600;

Dayak

Any explanation ? – Yapon

Answer 32

you can simply try this. it will return you current machine time

var _d = new Date(), t = 0, d = new Date(t*1000 + _d.getTime())

Murmurous

This is how should be done I think: new Date(new Date().getTime()); it would display: "Fri Dec 28 2018 10:15:23 GMT+0100 (Central European Standard Time) {}" – Groveman

Answer 33

This will do the job.

---

var time = new Date(),
timestamp = Date(1000 + time.getTime());
console.log(timestamp);

---

Thu May 25 2017 21:35:14 GMT+0300 (IDT)

undefined

Warrant