Date.prototype.getTimezoneOffset()

The only Date method whose whole purpose is to describe the runtime. Its sign convention is inverted relative to ISO 8601, and its value depends on the date because of daylight saving.

Date methodES1 (1997)Live demo
Common call
d.getTimezoneOffset()
Returns
minutes to add to local to get UTC
Replaces
nothing — it is the only way to ask
Watch out
UTC+2 reports −120, and it CHANGES with the date
date.getTimezoneOffset()
→ number

Demo

Live evaluation
Try:
Inputs
isostringa date — the offset depends on it
Output
new Date('2026-07-15T12:00:00Z').getTimezoneOffset()
0

This number is YOURS — it describes wherever you are reading this from, so no two readers necessarily see the same output. If you are in UTC it is 0; west of Greenwich it is positive; east it is negative. Compare the summer and winter cases: if they differ, your region observes daylight saving, and the offset is a property of the DATE as much as of the place. That is why caching a single offset and applying it to other dates is wrong.

Common patterns

Report the offset in ISO form
Negate it, because the signs are opposite.
const o = -d.getTimezoneOffset();
const sign = o >= 0 ? '+' : '-';
Name the zone instead
Far more useful than a number.
Intl.DateTimeFormat().resolvedOptions().timeZone;
Format in a specific zone
No offset arithmetic at all.
d.toLocaleString('en-GB', {timeZone: 'Asia/Tokyo'});

Examples

1. UTC
new Date().getTimezoneOffset()
Returns
0 in UTC
2. New York in winter
new Date("2026-01-15").getTimezoneOffset()
Returns
300 there — UTC−5
3. Berlin in summer
new Date("2026-07-15").getTimezoneOffset()
Returns
−120 there — UTC+2
4. It varies by date
new Date("2026-01-15").getTimezoneOffset() !== new Date("2026-07-15").getTimezoneOffset()
Returns
true where DST applies
5. The zone name
Intl.DateTimeFormat().resolvedOptions().timeZone
Returns
'Europe/Berlin', for example
6. No UTC variant
typeof new Date().getUTCTimezoneOffset
Returns
'undefined'

Pitfalls

1. The sign is inverted
It returns the minutes to ADD to local time to reach UTC, so a zone written as UTC+2 reports −120. Every piece of code that builds an ISO offset string from this value needs a negation, and forgetting it puts the timestamp twice the offset away from where it should be.
Backwards
new Date().getTimezoneOffset()
−120 in a UTC+2 zone
Negate for display
-new Date().getTimezoneOffset()
120, matching UTC+2
2. It depends on the date, not just the place
Daylight saving means one location has two offsets a year. Reading the offset once at startup and applying it to other dates is wrong for half the year, and the bug appears on a schedule nobody is testing against.
Cached
const OFFSET = new Date().getTimezoneOffset();
wrong after the DST change
Per date
const offset = someDate.getTimezoneOffset();
correct for that date
3. It is minutes, not hours
And not always a whole number of hours — India is UTC+5:30 and reports −330, Nepal is UTC+5:45. Dividing by 60 and truncating loses the fraction for hundreds of millions of people.
Loses the half hour
Math.trunc(-330 / 60)
−5
Keep the minutes
`${Math.trunc(330 / 60)}:${330 % 60}`
'5:30'
4. An offset is not a timezone
Two regions can share an offset today and diverge in a month because their DST rules differ. Storing the offset loses the information needed to render any other date correctly — store the IANA zone name instead.
Ambiguous
save({offset: -120})
which zone was that?
Store the name
save({tz: Intl.DateTimeFormat().resolvedOptions().timeZone})
'Europe/Berlin'

When to use

Use it
  • Reporting or logging the runtime offset for diagnostics
  • Building an ISO offset suffix, with the sign negated
  • Detecting whether the runtime is in UTC
Reach for something else
  • Converting between timezones → Intl with a timeZone option
  • Storing a user timezone → the IANA zone name
  • Assuming whole hours → some zones are offset by 30 or 45 minutes
  • Caching the value → it changes across DST boundaries

Notes

Complexity
O(1), with a timezone-database lookup
Return
A number of minutes; NaN for an invalid Date
CPython impl
V8: Builtins-date-gettimezoneoffset / ICU timezone data
Memory
No allocation
Thread-safe
Single-threaded; the value reflects the process timezone setting

FAQ

Because the method is defined as the adjustment needed to get from local time TO UTC, not the offset of local time from UTC. Those are opposites. ISO 8601 writes +02:00 for a zone that this method reports as −120.

const isoOffsetMinutes = -d.getTimezoneOffset();

History

ES1
getTimezoneOffset present from the first version, with the inverted sign convention.
ES2012
ECMA-402 added Intl, giving access to named timezones and making manual offset arithmetic unnecessary.