1083

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)
7

34 Answers 34

1330
+100

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.

Sign up to request clarification or add additional context in comments.

10 Comments

moment.js makes use of it where supported. Otherwise falls back to getTimezoneOffset().
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
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
@XavierPoinas it's accessible from the Intl object Intl.supportedValuesOf('timeZone') ! (then you can use locale "ia" to get the offset)
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?
|
788

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

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).

13 Comments

@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.
var hrs = -(new Date().getTimezoneOffset() / 60) to get offset in hours typically used
Seems it does not consider daylight saving time
timezone != utc offset
Intl.DateTimeFormat().resolvedOptions().timeZone will give the timezone of cient.
|
161

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)" :

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

For "GMT-0400" :

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

For just "EDT" :

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

For just "-0400":

console.log(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.

13 Comments

Broken with Chrome as it appends the name of the timezone. Do not use split.length but a constant instead split[4] + " " + split[5] ?!
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
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!
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
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.
|
87

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}`
}

5 Comments

This returns the time zone offset (eg: UTC+01), it does not return the time zone (eg: Europe/London)
@Flimm better to use the moment and moment-timezone library for that. We can't have that in two lines code.
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');'
Thanks @AdrianSanchez. fixed it. It actually worked in min code but not the commented code.
Or with Luxon.js (successor of Moment.js), you could use const d = Luxon.fromJSDate(dateTime).toFormat('yyyy-MM-dd\'T\'HH:mm:ssZZ');
84

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))

4 Comments

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
this will give correct result: this.pad(Math.floor((Math.abs(offset/60))), 2)
Instead of using your pad function, I find it easier to do this: offset = (offset<0 ? "+" : "-") + ("0000" + parseInt((Math.abs(offset/60)))).slice(-4)
replace parseInt(...) with (...)|0 or Math.floor(...). Why would you convert it to a string and then back to an number?
80

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

3 Comments

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.
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.
@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.
53

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.

2 Comments

"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
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.
23

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. :)

Comments

17

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.

Comments

10

JavaScript:

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

1 Comment

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

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://stackoverflow.com/a/64262840/1061871)

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

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))

Comments

9

Try this :

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

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

4 Comments

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"
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.
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.
Just Intl.DateTimeFormat().resolvedOptions().timeZone
7

With moment.js:

moment().format('zz');

5 Comments

z and zz have been deprecated as of 1.6.0 see momentjs.com/docs/#/displaying/format
@MrUpsidown it is now Z and ZZ
@brauliobo 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.
Latest docs show .zoneAbbr() has replaced zand zz. See documentation here
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.
7

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

2 Comments

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.
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.
6

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));
}

6 Comments

Does not work for timezones when it is not a full hour, like Venezuela, where it return GMT-4.5
Yes, that is right. 0.5 means 0.5*30 mins. I think you got this why it is giving 0.5?
yes, so GMT-4.5 is not a valid timezone, it needs a bit of extra parsing to become GMT-4:30
@Mirko now second part of the answer is for you
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)
|
6

With , 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 , 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.

2 Comments

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.
"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().
5

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

4 Comments

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.
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
"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
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
2

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

1 Comment

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.
2

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

enter image description here

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)

4 Comments

incase of negative value, some issue
Why round? It should be floor, isn't it?
This returns the time zone offset (eg: UTC+01), and not the time zone (eg: Europe/London)
I am in California and your code prints out +-8:0.
1

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

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)

1 Comment

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.
1
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

1 Comment

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

Try this,

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

1 Comment

Using Date.toString() is not reliable.
1

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());

4 Comments

Using Date.toString() is not reliable, and MDN explains why. I've pasted the relevant section from their docs in my answer.
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
That is not the timezone. That is a name of the offset. Offset != Timezone. The timezone stays the same, the offset does not.
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.
1

16 years later and we have Temporal starting to appear in browsers, making date matters much simpler. In this case both timezone and offset can be obtained easily thus:

if ('Temporal' in window) {  
  console.log(Temporal.Now.timeZoneId())
  console.log(Temporal.Now.zonedDateTimeISO().offset)
}

Right now only the latest version of Firefox has it implemented.

Reference: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal/Now

Comments

0

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.

2 Comments

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.
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'.
0

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);

2 Comments

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?
And this is also wrong and copy-pasted. Badly.
-1

Use this to convert OffSet to postive:

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

1 Comment

x + (-2*x) === -x.
-1

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.

5 Comments

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
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
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.
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
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.
-1

Why not just use:

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

1 Comment

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.
-1

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'));

2 Comments

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.
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 stackoverflow.com/q/15141762 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

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.