Date UTC methods (getUTCHours, setUTCMonth…)

Fifteen methods that duplicate the local family with UTC as the basis. Reach for these whenever the answer must not depend on where the code happens to run.

Date methodsES1 (1997)Live demo
Common call
d.getUTCDate()
Returns
the component in UTC
Replaces
the local getters, on a server or in shared data
Watch out
getUTCMonth is still 0-indexed
date.getUTCHours(), date.getUTCDate(), date.setUTCMonth(m)
→ number

Demo

Live evaluation
Try:
Inputs
isostringan ISO date, e.g. 2026-03-15T12:00:00Z
Output
(d => [d.getUTCHours(), d.getHours()])(new Date('2026-03-15T12:00:00Z'))
[12, 12]

The pair is [getUTCHours(), getHours()]. The first number is the same for every reader of this page. The second is whatever YOUR timezone makes of that instant — if the two numbers differ, that gap is your UTC offset, and if they happen to match you are reading this from UTC. The third case is the one that causes dated bugs: at 23:00 UTC a reader east of Greenwich is already on the following DAY, so getDate and getUTCDate disagree about the date entirely, not just the hour.

Parameters

NameTypeRequiredDescription
valuenumberno (none)For the setUTC family only. Same rollover behaviour as the local setters — an out-of-range value adjusts the larger components.

Return value

number — The same components as the local family, computed in UTC — so the answer is identical everywhere in the world for a given timestamp.

Common patterns

Consistent date keys
Group records by UTC day, not the server day.
const key = `${d.getUTCFullYear()}-${d.getUTCMonth() + 1}-${d.getUTCDate()}`;
Build a UTC date from parts
Date.UTC avoids the setter dance.
const d = new Date(Date.UTC(2026, 2, 15));
Local time for display only
Store and compute in UTC, format at the edge.
d.toLocaleString(undefined, {timeZone: 'UTC'});

Examples

1. UTC hour
new Date('2026-03-15T12:00:00Z').getUTCHours()
Returns
12
2. UTC month still 0-based
new Date('2026-03-15T12:00:00Z').getUTCMonth()
Returns
2
3. UTC date
new Date('2026-03-15T23:00:00Z').getUTCDate()
Returns
15
4. Local may differ
new Date('2026-03-15T23:00:00Z').getDate()
Returns
15 or 16, depending on the runtime
5. setUTCMonth rolls over too
const d = new Date(Date.UTC(2026, 0, 31)); d.setUTCMonth(1); d.toISOString().slice(0, 10)
Returns
'2026-03-03'
6. Date.UTC builds a timestamp
Date.UTC(2026, 2, 15)
Returns
1773532800000

Pitfalls

1. getUTCMonth is still zero-based
Switching to the UTC family fixes the timezone problem and changes nothing about the indexing. The +1 is still required, and mixing local and UTC methods in one format string is a reliable way to produce a date that is wrong by both a month and a day.
Still off by one
`${d.getUTCMonth()}/${d.getUTCDate()}`
'2/15' for 15 March
Add one
`${d.getUTCMonth() + 1}/${d.getUTCDate()}`
'3/15'
2. Mixing local and UTC methods
Reading the year locally and the month in UTC produces a date that exists in neither basis. Near midnight on 31 December the two disagree about the year, and the result is a full year out.
Two bases
d.getFullYear() + "-" + d.getUTCMonth()
inconsistent near midnight
Pick one
d.getUTCFullYear() + "-" + d.getUTCMonth()
consistent
3. UTC is not the same as "no timezone"
A timestamp is an instant, and UTC is one way of naming its parts. Storing a wall-clock time that is meant to be local — a 09:00 appointment in Berlin — as UTC loses the intent as soon as daylight saving shifts. For those, store the local time and the timezone name separately.
Intent lost
new Date(Date.UTC(2026, 2, 15, 8))
an instant, not "09:00 in Berlin"
Store both
({local: '2026-03-15T09:00', tz: 'Europe/Berlin'})
intent preserved
4. There is no getUTCTimezoneOffset
It would always be zero, so the method does not exist. getTimezoneOffset is inherently about the runtime, which is why it is the one method with no UTC counterpart.
Does not exist
new Date().getUTCTimezoneOffset()
TypeError: ...is not a function
It is always 0
0
0

When to use

Use it
  • Server-side code, where the machine timezone is an accident
  • Grouping or bucketing by day across users in different zones
  • Anything stored, compared or transmitted
  • Reproducible tests that must not depend on the runner timezone
Reach for something else
  • Showing a time to a person → the local getters, or Intl with their timezone
  • Wall-clock intent that must survive DST → store the zone name too
  • Formatting → toISOString or toLocaleString

Notes

Complexity
O(1) each, and marginally cheaper than the local family — no timezone lookup
Return
A number from the getters; a timestamp from the setters, which mutate
CPython impl
V8: Builtins-date UTC getters and setters
Memory
No allocation
Thread-safe
Single-threaded

FAQ

On a server, close to it — the machine timezone is usually incidental and letting it leak into stored data causes bugs that only appear after a deployment moves. In the browser, use the local family when showing a time to the person sitting there, and UTC for anything you send or store.

History

ES1
The UTC getter and setter families present from the first version, mirroring the local ones.