REZSAT / DEVELOPER WORKFLOW

Unix timestamps: seconds, milliseconds and UTC without the usual mistakes.

An API returns 1700000000000. Another returns 1700000000. They describe the same instant but use different units. Before blaming timezones or daylight saving time, check whether you accidentally multiplied a timestamp by a thousand.

RezSat Editorial2026-11-057 min read

The epoch is a fixed reference point

Unix timestamps count time relative to 1970-01-01T00:00:00Z, the Unix epoch. A positive timestamp is after that instant and a negative timestamp can represent a time before it. The underlying count does not contain a timezone, city or daylight-saving label.

A common representation uses seconds. JavaScript's Date.now() instead returns a number of milliseconds since the epoch. Multiply a seconds timestamp by 1000 to supply milliseconds to JavaScript Date; divide a milliseconds timestamp by 1000 if an API needs seconds.

One instant, two different numbers

Take 1700000000 seconds. The equivalent millisecond value is 1700000000000. Both correspond to 2023-11-14T22:13:20Z in UTC. You can paste either number into the Unix Timestamp Converter using the appropriate unit setting and check the ISO 8601 output.

The rough 10-digit versus 13-digit heuristic works for many modern dates, but it is not an actual type declaration. Historic dates, future dates and unusually encoded systems can break that shortcut. Read the source API documentation.

UTC versus a displayed local time

The Z suffix on an ISO timestamp identifies UTC. If an event occurred at 2023-11-14T22:13:20Z, a display using the offset +05:30 would show 2023-11-15T03:43:20+05:30. Different clock readings do not mean different events.

A numeric offset is not a complete timezone policy. Daylight-saving rules and historical changes depend on named regions. When planning events in a specific place, store an appropriate timezone as well as a time where the application needs future local scheduling.

Three checks before debugging the wrong thing

First, confirm the unit in the source field. Second, convert to an explicit UTC ISO timestamp and compare it with a trusted log. Third, decide which local display timezone is actually required. Changing all three at once makes a simple bug hard to isolate.

If the input is an informal date string without Z or an offset, parsing may depend on the environment and input format. Prefer explicit ISO 8601 dates when exchanging data. RezSat converts supported values in your browser; it cannot guess what a missing timezone was intended to mean.

Useful links and sources

These links point to the original tool or official documentation. Features and free-tier limits may change.