Unix timestamps, UTC, and local time

Short answer

A timestamp identifies an instant; UTC and local time are ways to display it. The Unix number does not change when you travel from Madrid to Mexico City, but the visible date and clock time do.

One instant, multiple representations

Timestamp: 1767225600 s
UTC:       2026-01-01 00:00:00Z
Madrid:    2026-01-01 01:00:00 (winter)

Do not add one hour to the timestamp to “convert it to Madrid.” Keep the instant and apply the zone only when displaying it or interpreting a local clock time.

When to choose UTC

UTC is a suitable basis for logs, expiration times, cross-system events, and stored instants. It prevents the value from changing meaning with the machine that reads it. An ISO date ending in Z declares UTC explicitly.

Local time matters when the human intention belongs to a place’s calendar: a 09:00 appointment, shop opening hours, or a daily task. In those cases, retain the zone identifier as well as the time. A fixed offset such as +01:00 does not contain future or date-specific clock-change rules.

Daylight-saving transitions

During a spring transition, the clock jumps and a range of local times never occurs. During an autumn transition, a range repeats and one local time can map to two instants. One fixed offset cannot handle both cases.

The date and timestamp converter rejects a nonexistent local time and warns when the browser’s zone makes it ambiguous. Choose UTC when the conversion must be reproducible across countries.

Checklist

• Does the input include Z, an offset, or a known zone?
• Is the system storing an instant or a recurring civil time?
• Is the timestamp unit explicit?
• Has a clock-change date been tested?
• Does the interface display the zone with the result?

An error of exactly one or two hours often points to a time-zone mistake; a factor of one thousand usually indicates seconds versus milliseconds.

Primary source

The ECMAScript Date specification distinguishes the UTC time value from operations that present it as local time.