← All guides Updated

UTC vs local time: which should you use?

UTC is a single, global reference clock. Local time is what your watch on the wall says, adjusted for your time zone and (often) for daylight saving. They describe the same instant from two different angles: UTC is for computers and coordination, local time is for humans and habits.

Rule of thumb: store and transmit time in UTC. Display in local time. Convert between the two only at the edge of your system — never in the middle.

What "local time" actually means

Local time is the reading on a clock in a specific place. It's a combination of the place's time zone (e.g. Europe/London) and the current UTC offset (e.g. UTC+0 or UTC+1). The offset can change with the seasons because of daylight saving, with politics (some countries permanently change their offset), and even with rare leap seconds.

That makes local time inherently unstable. A meeting "next Sunday at 02:30" might be ambiguous (during the autumn DST rollback, that hour happens twice) or non-existent (during the spring forward, that hour is skipped). Local time is fine for end users; it's a nightmare for storage.

What UTC actually means

UTC is a continuous count of seconds, anchored to atomic clocks. It does not observe daylight saving, does not pause, and does not depend on geography. Every networked computer, every cloud database, every phone app stores time in UTC under the hood. When you read a tweet posted "2 minutes ago", the system is comparing your current UTC time to the tweet's UTC timestamp, then converting the difference into a human-readable phrase in your locale.

When to use UTC

When to use local time

Storing local time without losing information

Sometimes you genuinely need to remember a local-time intent: "the wedding starts at 16:00 local time in Paris on 2026-06-12, regardless of any future DST law changes". For these cases, store both the local clock value and the IANA zone (Europe/Paris). Then re-derive the UTC timestamp at run time from the latest IANA database. This pattern is sometimes called "floating time with a zone".

Common pitfalls

  1. Storing only "20:00" with no zone. You'll never know whether that's UK summer time or US Pacific Standard Time later.
  2. Hard-coding offsets. Code that says "add 8 hours for China" only works because China happens not to have DST. Most zones do, and your code will silently break in March.
  3. Treating UTC as English time. UTC is not Western Europe and not Britain. It's a global coordinate that happens to coincide with London winter time.
  4. Mixing offsets. ISO 8601 lets you write 2026-04-27T14:00:00+01:00; this is unambiguous. Just remember the offset is a snapshot, not the zone.

FAQ

Should I store dates as UTC or local time?

UTC, almost always. The exceptions (recurring local events, scheduled events tied to a wall clock) need both UTC and a zone, not just one or the other.

Is UTC affected by daylight saving?

No. UTC never shifts. Local time shifts; the difference between UTC and local is what "moves".

Why does my browser sometimes show UTC and sometimes local?

Most date APIs default to local time. Functions like Date.prototype.toISOString() in JavaScript return UTC; toLocaleString() returns local. Check the function you're calling.

Related guides