Instant, clock reading and unit
A Unix timestamp is a count of seconds relative to the Unix epoch at 1970-01-01 00:00:00 UTC. An ISO-style date-time spells out calendar fields and, when it identifies an instant, includes an offset such as Z or +01:00. A plain wall-clock reading without a zone does not determine one unique instant. Also check the timestamp unit: browser and JavaScript Date APIs commonly use milliseconds, a number one thousand times larger than Unix seconds for the same moment. MultiVerto's Unix tool expects seconds and accepts up to three decimal places for milliseconds. It renders the result in UTC with a Z suffix, making the assumed reference explicit.
One new year in two clocks
Enter 1704067200 in the embedded converter. It represents 2024-01-01T00:00:00.000Z. The same instant can be written 2024-01-01T01:00:00+01:00: the local clock is one hour ahead, so subtracting its positive one-hour offset returns midnight UTC. Paste that offset-bearing value into the linked ISO-to-Unix tool and it returns 1704067200. A date written as 2024-01-01T01:00:00Z would be a different instant, exactly one hour later. The digits in the calendar part are not sufficient without the suffix. This worked pair is a useful regression test for logging and API integrations.
- Unix: 1704067200 seconds
- UTC: 2024-01-01T00:00:00.000Z
- Offset: 2024-01-01T01:00:00+01:00
Seconds, milliseconds and fractions
When an API returns a 13-digit-looking contemporary epoch value, check whether its contract says milliseconds instead of seconds; do not infer the unit solely from length for every possible date. To turn milliseconds into seconds, divide by 1000 while preserving any intended fraction. For example, 1704067200500 milliseconds corresponds to 1704067200.5 seconds and 00:00:00.500Z on the example date. MultiVerto accepts at most three digits after the decimal point and returns an ISO output with millisecond precision. If a system records microseconds or nanoseconds, preserve those in a tool designed for that scale before rounding. Early rounding can make closely spaced events appear simultaneous.
An offset is not a time-zone history
A numeric offset tells you how a particular local clock relates to UTC at that timestamp. It does not name a region or encode future daylight-saving rules. A recurring appointment at 09:00 in a named location needs a real time-zone database, not a permanently fixed +01:00. MultiVerto requires an explicit offset or Z for its ISO-to-Unix input, preventing an ambiguous local reading. Its accepted format uses a full calendar date, time through seconds and no more than three fractional digits. It rejects invalid dates and leap-second value 60. That is a deliberate subset of broader date-time notations, so check the actual input contract before pasting external data.
A reliable round-trip check
Write down the source value, whether it is seconds or milliseconds, and the time-zone or offset specified by its producer. Convert the timestamp to UTC ISO text, then reverse that exact string and compare the numeric seconds. Next, test a second spelling with an explicit offset representing the same instant. If values differ by exactly 3600 seconds, suspect a one-hour offset mistake; if they differ by a factor of 1000, suspect unit scale. Do not change a logged instant merely to make its displayed clock resemble your local clock. Store the instant in an unambiguous form and format it for a user only at the display boundary.