Unix Timestamps: Seconds, Milliseconds, and Time Zones Explained

A Unix timestamp is best treated as an instant, not as a formatted local date. The common source of confusion is that one system may send a count in seconds, another sends milliseconds, and the screen where you read it applies a time zone. Those are separate choices.

This guide answers a practical question: when a timestamp turns into the wrong date or time, how can you identify its unit and display the same instant correctly?

Start by identifying the unit in the system contract

In POSIX terminology, the Epoch begins at 1970-01-01 00:00:00 UTC; system time is measured relative to it. 1 Many APIs and databases represent that count as whole seconds, while JavaScript's Date constructor and Date.now() use milliseconds. The number alone does not reliably declare its unit.

For example, these two values represent the same instant when interpreted with their stated units:

1704067200 seconds      = 2024-01-01T00:00:00Z
1704067200000 milliseconds = 2024-01-01T00:00:00Z

Do not decide solely from the number of digits. A digit-count shortcut can be useful for a recent date, but it becomes fragile for historical values, future values, fractional seconds, and values with leading zeroes in a text format. Check the API documentation, column name, schema, or code that creates the value. Names such as created_at_ms, epochSeconds, and expiresAt can be clues, but the documented contract is the authority.

If the source is unavailable, test each plausible unit against a known event: a log entry, receipt, deployment, or message whose time is independently recorded. Record the unit once you establish it; repeatedly guessing during an incident is how a silent factor-of-1,000 error spreads.

Separate the instant from its display time zone

An epoch count does not carry a city, offset, or daylight-saving rule. It identifies an instant relative to the Epoch. A viewer then formats that instant using a chosen zone, which is why the same value can show different clock times on two machines without either conversion being wrong.

Use UTC when comparing events across systems. In RFC 3339, the Z suffix denotes UTC, while a numeric offset identifies local time relative to UTC. 2 3 These are two representations of one instant:

2024-01-01T00:00:00Z
2023-12-31T19:00:00-05:00

When you need a person to act at a local time, include the offset in the displayed value and, when relevant, retain the named time zone separately in the application data. An offset such as -05:00 describes the relationship to UTC at that moment; it does not by itself express the future daylight-saving rules for a place. RFC 9557 defines an optional bracketed time-zone-name extension for RFC 3339 and explains that an offset alone is not sufficient to determine the offset at another time. 4

Convert safely without changing the instant

Use this sequence whenever a timestamp looks suspicious:

1. Preserve the original value exactly, including any decimal portion and its source field name.
2. Establish whether the value is seconds, milliseconds, microseconds, or another documented unit.
3. Convert it to a UTC representation first, preferably an RFC 3339 value ending in Z.
4. Compare that UTC result with an independently known event.
5. Format the confirmed instant in the reader's required time zone only for display.

The yukt.tools homepage lists timestamps among its utility topics. A conversion utility can be convenient for a non-sensitive sample, but it cannot determine the source unit or the business meaning of a field for you. Do not paste credentials, personal data, signed URLs, or production logs into a web tool unless you are authorized to disclose them.

Avoid the three common failure modes

Treating milliseconds as seconds

If a millisecond value is passed to a seconds-based converter, the output can land implausibly far in the future. The reverse mistake commonly produces a date near 1970. The remedy is not to add or remove zeroes until the display looks familiar; confirm the unit, then convert once.

Parsing a date-time with no offset as if it were universal

2024-01-01T09:00:00 states a wall-clock date and time but does not identify its relationship to UTC. RFC 3339 requires either Z or a numeric offset in its full date-time format. 3 If a producer omits that information, ask what zone was intended before comparing it with an epoch value.

Ordering formatted strings instead of instants

Local date strings can sort differently from event order around midnight or across offsets. For chronological comparisons, retain a normalized instant such as an epoch value in a documented unit or a UTC date-time. Format for people at the boundary of the system, not as the only stored representation.

A small diagnostic example

Suppose an audit log says an action occurred at 1704067200, while a support report says it happened at 2023-12-31 19:00 in a location five hours behind UTC. First, document that the log field is in seconds. Converting it yields 2024-01-01T00:00:00Z. Formatting that instant with -05:00 yields 2023-12-31T19:00:00-05:00.

The date change is expected: midnight UTC falls on the previous calendar date in that offset. The records agree once they are expressed as the same instant. If the reported local time did not include an offset or a named zone, it would not be sufficient evidence to make that conclusion.

Frequently asked questions

Is a Unix timestamp always in UTC?

The underlying count is relative to the POSIX Epoch, whose beginning is defined in UTC. It does not embed a display time zone. UTC versus local time becomes relevant when software formats the instant into a human-readable date and time, so write the chosen offset or Z alongside a displayed value. 1 2

How can I tell whether a Unix timestamp uses seconds or milliseconds?

Use the source system's documented contract or a known event time. Digit length can suggest a likely unit for modern values, but it is not a proof: dates outside the current era, fractional values, and text formatting make the shortcut unreliable. Once confirmed, label the field’s unit so the next consumer does not have to infer it.

Why did converting a timestamp change the calendar date?

The instant did not change; the display zone did. A UTC time shortly after midnight can still be the previous calendar day in a negative offset, and a time shortly before midnight can be the next calendar day in a positive offset. Compare normalized instants first, then format them for the audience that needs to read them.

Sources and research

1. The Open Group Base Specifications, section 4.19: Seconds Since the Epoch — primary POSIX definition of the Epoch and seconds since it, accessed 2026-09-30.
2. RFC 3339, section 4.1: UTC Offset — IETF specification for UTC offsets in Internet date-times, accessed 2026-09-30.
3. RFC 3339, section 4.3: Internet Date/Time Format — IETF specification for the full date-time form and required offset, accessed 2026-09-30.
4. RFC 9557, section 3.1: Time Zone Information — IETF specification explaining time-zone-name annotations and why an offset alone cannot establish a future offset, accessed 2026-09-30.