Unix Timestamp Converter: Seconds, Milliseconds & Dates

A Unix timestamp looks like a random number until you need to read it. A log line shows 1700000000; a JavaScript payload shows 1700000000000; a database column shows 2023-11-14 22:13:20+00. All three can describe the same instant. The conversion is simple once you know the unit and the reference point, and most mistakes come from mixing seconds with milliseconds or reading a UTC value as local time.

This guide is part of the age calculator guide. Open the Unix timestamp converter to check each example as you read.

Two questions decide every conversion: which unit the number is in, and which zone should display it. The epoch and the arithmetic are fixed; the display is a choice. Keep those separate and a timestamp stops being mysterious.

What Unix time actually counts

Unix time counts seconds from 1970-01-01T00:00:00Z, the epoch, in UTC. 0 is that instant. 86400 is 1970-01-02T00:00:00Z because one day has 86,400 seconds. The number is not a clock face and carries no timezone; it names one instant on the global timeline.

Why 1970? It was a convenient origin for early Unix systems, close enough to their own era to keep values small and far enough back to cover useful history. The choice is a convention, not an astronomical event. Other systems use different origins, which is why a timestamp from a Windows file property or a GPS receiver should not be pasted into a Unix converter without checking its epoch.

The count ignores leap seconds. Unix time treats every day as 86,400 seconds, so the UTC label around an inserted leap second can differ from a strict count of SI seconds. For ordinary logging, scheduling and date arithmetic that difference is irrelevant. For precision timing systems, it is not.

Timestamps can be negative: -86400 is 1969-12-31T00:00:00Z. They also have a range limit on older systems. A signed 32-bit seconds value stops at 2147483647, which is 2038-01-19T03:14:07Z. That is the much-discussed 2038 problem. Modern 64-bit systems handle dates far beyond it, but embedded devices and old database columns may not.

Seconds vs milliseconds: how to tell them apart

Unix seconds and Unix milliseconds share the same epoch and differ by a factor of 1,000. 1700000000 seconds and 1700000000000 milliseconds are the same instant. Digit length is the quickest check: a present-day seconds value has 10 digits, and the same instant in milliseconds has 13. A 16-digit value is usually microseconds, which require dividing by 1,000,000.

APIs disagree about units. Many HTTP APIs and database functions return seconds; JavaScript's Date.now() returns milliseconds. If a converted date lands in 1970 or in the year 56,000, the unit is wrong by a factor of 1,000. Divide or multiply once and recheck the year before doing anything else.

The ISO row is not a different time; it is a different notation. The trailing Z means UTC, so an ISO string with a Z and a Unix timestamp can be compared directly. An ISO string with +05:30 or -04:00 describes the same kind of instant with an explicit offset attached.

Which unit should you store?

Store the unit your consumers expect, and write it into the field name or schema. A column called created_at with no unit is a future bug; created_at_ms or an ISO 8601 text field removes the guess. Milliseconds are convenient for JavaScript and for ordering events that occur within the same second. Seconds are smaller and match many APIs. Microseconds and nanoseconds appear in instrumentation and high-resolution logs, where 16 or 19 digits are normal.

When a value arrives without documentation, test it against a known event. A 10-digit value near 1.7 billion is late 2023 in seconds; the same digits with three more zeros are milliseconds. A 9-digit number is 2001 or earlier in seconds, while a 12-digit number is likely milliseconds between 1973 and 2001, or a non-Unix epoch. The year is the tell, not the digit count alone.

Converting in both directions, with the arithmetic shown

To convert seconds to UTC, divide by 86,400 to get whole days after the epoch, then turn the remainder into hours, minutes and seconds. Example 1: 1,700,000,000 seconds. The division gives 19,675 days with a remainder of 80,000 seconds. 80,000 seconds is 22 hours (79,200), 13 minutes (780) and 20 seconds. Day 19,675 after 1970-01-01 is 2023-11-14, so the instant is 2023-11-14T22:13:20Z.

To go the other way, count the days from the epoch and multiply. Example 2: 2024-01-01T00:00:00Z is 19,723 days after the epoch. 19,723 × 86,400 = 1,704,067,200, so the timestamp is 1704067200. Example 3: 2024-03-01T00:00:00Z is 60 days later, because January has 31 days and February 2024 has 29. 60 × 86,400 = 5,184,000, and 1,704,067,200 + 5,184,000 = 1,709,251,200. That matches 2024-03-01T00:00:00Z.

For milliseconds, multiply the seconds result by 1,000. The 2024-01-01 example becomes 1,704,067,200,000 milliseconds. Going back, divide by 1,000 before doing the day arithmetic. For microseconds, divide by 1,000,000. Doing the day division on a millisecond value is the single most common conversion error, and it produces a date tens of thousands of years away.

Fractional seconds are not part of the integer count. 1700000000.5 is half a second after the whole-second instant, and ISO would show 2023-11-14T22:13:20.500Z. If a system truncates the fraction, two events can appear in the wrong order. Keep the fractional part when ordering high-frequency logs, and round only when displaying a human-readable time.

Where timezones and daylight saving enter

A timestamp does not change when you change timezones; the local rendering does. 1,700,000,000 is 2023-11-14T22:13:20Z everywhere. On that date New York was on EST, UTC−5, so the local clock read 17:13:20. Berlin was on CET, UTC+1, so it read 23:13:20. Tokyo was at UTC+9, so it read 07:13:20 on 15 November. The instant is identical; the labels differ.

Offsets are rules, not constants. New York uses EST in winter and EDT in summer, and the switch dates are set by local law. A timestamp near a boundary can therefore render with one offset in January and another in July. For example, 2026-03-08 05:00 UTC is 00:00 EST in New York. At 07:00 UTC that same morning, the city has sprung forward and the local time is 03:00 EDT. The two-hour UTC gap contains a one-hour local jump, not a missing timestamp.

That is why logs should store UTC and render in a named IANA zone such as America/New_York, not a fixed UTC-5. A fixed offset is correct only until the next clock change. Use the timezone conversion guide for meeting-time examples, and keep the zone name with any timestamp you archive.

When you render a timestamp for a user, show the zone abbreviation or the offset alongside it. "22:13" is ambiguous; "22:13 UTC" or "17:13 EST" is not. The converter's local pane uses the device zone, which may not be the zone the user expects if they are travelling or if the browser is set to a different region.

Common mistakes that produce the wrong date

1. Treating milliseconds as seconds. The year jumps to roughly 56,000. Divide by 1,000 before converting.
2. Treating seconds as milliseconds. The date collapses to January 1970. Multiply by 1,000 and look again.
3. Reading a UTC timestamp as local. A log stamped 22:13Z is not 22:13 in New York; it is 17:13 EST that day.
4. Using a fixed offset for a DST zone. A value that is correct in January is off by an hour in July. Use the IANA zone and a date-aware conversion.
5. Dropping the Z. An ISO string without a zone can be interpreted as local time by the receiving system, which shifts the instant.
6. Assuming 2038 is only a hardware problem. Any database column or API field still storing signed 32-bit seconds has the same ceiling.
7. Confusing a duration with a timestamp. The number of seconds between two events is not a date. Adding 3,600 to a timestamp is fine; adding 3,600 to a duration is just arithmetic.

A quick sanity check catches most of these. A 2023 or 2024 timestamp in seconds sits near 1.7 billion; the same instant in milliseconds is near 1.7 trillion. If the digit count and the year do not agree, stop and check the unit before debugging the timezone.

A clean converter workflow

The timestamp converter accepts seconds or milliseconds and displays UTC and local versions together. Paste the value, confirm the digit count, compare the two panes, then copy the ISO string into your code or log. If you need to add days to a date rather than translate an instant, the date calculator handles calendar arithmetic without timestamp conversions.

1. Paste the number and note whether it has 10, 13 or 16 digits.
2. Check the UTC result against a known event or a second source.
3. Switch the local zone and confirm the offset for that specific date.
4. Copy the ISO 8601 string with its Z or offset attached.