Epoch to UTC — Unix Timestamp to Date

Epoch to UTC: a Unix timestamp is already counted from 1970-01-01T00:00:00Z, so converting to UTC is formatting, not offset math. The number has no timezone inside it. Timezones appear only when you display it as a local clock.

Seconds vs milliseconds (again)

Digits (typical)	Unit
10	seconds
13	milliseconds

Feeding milliseconds into an API that expects seconds jumps the date into the far future. See also: seconds vs milliseconds.

UTC vs local display

• UTC string — same everywhere (…Z or +00:00).
• Local string — depends on the machine or the timezone you pick (e.g. Asia/Kolkata).

Same epoch → two clocks on the wall. If a log says 15:00 and your converter says 20:30, you are probably mixing local and UTC, not “wrong epoch math.”

Practical workflow

1. Count digits → pick seconds or ms.
2. Convert to an ISO UTC time first.
3. Only then project into the timezone you care about.
4. When comparing two systems, agree on UTC storage and localize only in the UI.

Reading a timestamp at a glance

Digit count usually tells you the unit before you convert anything:

Digits	Unit	Example	Reads as
10	seconds	1768478400	2026-01-15
13	milliseconds	1768478400000	2026-01-15
16	microseconds	1768478400000000	2026-01-15
9 or fewer	seconds, but pre-2001	999999999	2001-09-09

The classic symptom of a unit mismatch is a date around the year 55,000 — that is milliseconds being read as seconds. The reverse mistake gives you 1970, because a seconds value read as milliseconds is only a few days past the epoch.

Where the offset actually comes from

An epoch has no timezone. The offset is applied at format time, from three possible sources, and they disagree more often than people expect:

• The server’s system clock zone. Often UTC in production and something local on a developer laptop — which is why a timestamp renders differently in staging and on your machine.
• The database session zone. Some drivers convert on read, so the same stored value can come back shifted depending on connection settings.
• The browser. new Date(ms).toString() uses the viewer’s own zone, so two users see different text for identical data.

If a value looks wrong by an exact number of whole hours — or by 5:30, 5:45, or 9:30 — it is almost certainly a formatting mismatch rather than bad data. Genuine data corruption rarely lands on a clean offset.

Daylight saving is the part that bites

For zones that observe DST, the offset is a function of the date being converted, not of today. Converting a July timestamp with a January offset is wrong by an hour, and hard-coding “UTC+1” for a zone that shifts guarantees a bug twice a year. Two edge cases worth knowing: when clocks go forward, some local times never happen at all; when they go back, some happen twice, so a local timestamp alone can be genuinely ambiguous. Storing UTC sidesteps both.

A rule that avoids most of this

Store epoch or UTC, convert only at the moment of display, and keep the timezone as separate data rather than baked into a formatted string. One moment of truth, formatted many ways — instead of many strings that each claim to be the truth.

Use TryDevSnip Epoch to UTC Converter

Just need the UTC date for one timestamp? Epoch to UTC gives you the UTC date, ISO 8601, and relative time directly. For epoch ↔ local-time conversion in any timezone, TryDevSnip Timestamp Converter has a live clock. Paste privately — not uploaded to our servers for processing.

FAQ

How do I convert a Unix timestamp to UTC?

Format the epoch as an ISO 8601 string with a Z suffix — no offset math needed, since epoch is already UTC-based. The Epoch to UTC tool does this instantly for seconds or milliseconds.

Does the timestamp change when I fly to another country?

No. The integer is the same. Only the formatted local time changes.

Should APIs store UTC or local?

Store UTC (or epoch). Localize for display.

Why is my date off by 5:30?

That is a classic IST (+05:30) vs UTC display mismatch — check which side you formatted.