Unix Timestamp Explained: Seconds Since 1970

The epoch is a reference point, not a time zone setting

A value of zero refers to the epoch reference instant. Positive values refer to later instants, and negative values can represent earlier ones in systems that support them. Different machines do not need to choose a new epoch for their local time zone; they can display the same instant with different local clock readings.

UTC is the reference used for the epoch definition. A local time display applies an offset or time-zone rule to show a calendar date and clock time. Changing that display does not change the underlying instant. Conversely, a calendar date without a time or time zone does not identify one unique instant.

The POSIX convention for seconds since the epoch does not provide a separate running count of leap seconds. If a system needs precise handling of those boundaries, use its specified time model rather than assuming every clock or scientific time scale behaves identically.

Seconds and milliseconds differ by a factor of 1,000

To convert seconds to milliseconds, multiply by 1,000. To convert milliseconds to seconds, divide by 1,000. Decide whether fractional seconds should be preserved or rounded according to the receiving system’s contract. Silently dropping the remainder can remove meaningful timing information.

Many contemporary positive timestamps have ten digits when expressed in seconds and thirteen in milliseconds. That is a useful clue, not a universal validation rule. Values near the epoch, negative values and dates in other ranges can have different lengths. Always prefer the documented unit over a digit-count guess.

A small JavaScript conversion you can check

const seconds = 1704067200;
const date = new Date(seconds * 1000);
date.toISOString();
// "2024-01-01T00:00:00.000Z"

The multiplication is essential here because JavaScript’s numeric Date input is in milliseconds. Passing 1704067200 directly as milliseconds produces an instant near the beginning of 1970 rather than the intended date in 2024. The value can therefore parse successfully and still represent the wrong date.

The final Z in the ISO string indicates UTC. A local formatter may display another clock time. Check the conversion by confirming the unit, the expected approximate calendar year, and the output time-zone label. A plausible-looking date is not enough if the system expects an exact boundary.

Local display can change the day as well as the hour

At the fixed offset UTC−05:00, the example instant displays as 2023-12-31 at 19:00. At UTC it displays as 2024-01-01 at midnight. Those are different calendar labels for the same instant, not conflicting timestamps. This is why a screenshot of a local date should include its time-zone context when it is used to investigate an incident.

A named time zone can change offsets during the year. A fixed offset string and a time-zone identifier are not interchangeable for future scheduling. Store the time-zone rules needed for a local appointment instead of assuming one offset is permanent. For an event that has already occurred, preserve the instant and the relevant display context.

Common mistakes in logs and API integrations

• Multiplying a value that is already in milliseconds, or forgetting to multiply a seconds value.
• Treating a ten- or thirteen-digit heuristic as a guaranteed unit detector.
• Comparing local date strings from different machines without their zones.
• Discarding fractional seconds even though ordering depends on them.
• Assuming a parseable timestamp proves that a claim or event is trustworthy.
• Using an instant-based representation when the data actually describes a calendar-only date.

Also distinguish event time from collection time. A log entry can describe when an event happened and when a server received it. Differences between those values may reflect buffering, transport delays or clock disagreement. Converting their units correctly does not answer which clock produced each value.

Make the unit and meaning explicit

When designing or reviewing an API, document whether a field means seconds or milliseconds, which event it represents, and whether fractions are allowed. A name such as createdAtSeconds is clearer than an unlabeled timestamp, although documentation and validation are still necessary. Verify the representation at both ends of a conversion.

JWT expiration and related time claims normally use seconds-based NumericDate values. The JWT explanation shows why reading those claims is only one part of understanding a token. For general conversion, choose the input unit explicitly and compare UTC with local output rather than relying on an automatic guess.