Unix Timestamps Explained: Seconds, Milliseconds and Time Zones

By the SAA Tool editor, an IT support engineer · Last reviewed 1 October 2026 · 6 min read

A Unix timestamp is a plain number, such as 1767225600, that pins down a single instant. Logs, databases, APIs and login tokens use them because one number is easy to store, sort and compare. The catches are that the number might be in seconds or milliseconds, and that it says nothing about time zones. This guide explains what the number counts, how to read it, and where conversions usually go wrong.

What the number counts

Unix time counts the seconds since the Unix epoch: 00:00:00 UTC on 1 January 1970. The POSIX standard, which Linux, macOS and most servers follow, calls it "seconds since the Epoch". So:

• 0 is 00:00:00 UTC on 1 January 1970.
• 1767225600 is 00:00:00 UTC on 1 January 2026.
• 1790812800 is 00:00:00 UTC on 1 October 2026.
• -86400 is 00:00:00 UTC on 31 December 1969. Negative values count backwards.

Every day adds exactly 86,400. POSIX defines each day as 86,400 seconds, so the leap seconds occasionally added to UTC are not counted. That makes Unix time slightly different from a true count of elapsed seconds, but it keeps date arithmetic simple: add 86,400 for tomorrow, 604,800 for next week. JavaScript's Date ignores leap seconds in the same way, and the expiry time inside a JSON Web Token (the exp claim) is also seconds since 1970, ignoring leap seconds. Our guide to Base64, URL encoding and JWTs shows how to read one.

One instant, many local times

A timestamp is the same number everywhere in the world at the same moment. Only the local clock reading differs. Here is 1767225600 in ten places:

Notice that the date itself changes: for people in the Americas it's still New Year's Eve. That's why a report "for 1 January" needs a time zone to mean anything.

Seconds, milliseconds, microseconds, nanoseconds

Different systems count in different units, and the quickest way to tell them apart is the number of digits:

Seconds timestamps have had 10 digits since 9 September 2001 and will keep 10 digits until 20 November 2286, so the digit test works for any current date. To convert milliseconds to seconds, divide by 1,000 and drop the decimals. To go the other way, multiply by 1,000.

Mix-ups are easy to spot once you know the symptoms. Read 1767225600 as milliseconds and you get 21 January 1970, 10:53:45 UTC. Read 1767225600000 as seconds and you land in the year 57971. So if a date shows up in January 1970, something was given seconds where it expected milliseconds (JavaScript's Date expects milliseconds). If it's tens of thousands of years away, it's the reverse.

Time zones: where most bugs come from

A timestamp has no time zone. To turn it into a local date and time, you need the rules for a place: its offset from UTC and its daylight-saving changes. Those rules are political and change over time, which is why software relies on the IANA Time Zone Database, a record of the history of local time for locations worldwide that is updated when governments change their offsets or daylight-saving rules.

• Use zone names, not abbreviations. Asia/Kolkata and Europe/Dublin are clear. "IST" can mean India, Irish or Israel Standard Time.
• Offsets aren't always whole hours. India is UTC+05:30 and Nepal UTC+05:45.
• Daylight saving moves the offset. New York is UTC−05:00 in January and UTC−04:00 in July. Sydney does the opposite, UTC+11:00 in January and UTC+10:00 in July, because summer there runs from December to February. Many countries, including Japan, India and the UAE, don't change their clocks at all.
• Some local times don't exist and some happen twice. In London on 29 March 2026 the clocks jump from 01:00 to 02:00, so 01:30 never happens. On 25 October 2026 the hour from 01:00 happens twice, so "01:30 London time" could be 1792888200 or 1792891800.

The safe habit is to store timestamps (or UTC) and convert to local time only when you display it. If you also need to know the user's local time later, for a recurring meeting for example, save the zone name alongside. When you exchange dates as text, include the offset, as RFC 3339 does: 2026-01-01T05:30:00+05:30 is the same instant as 2026-01-01T00:00:00Z, where Z means UTC.

One JavaScript surprise catches many developers: new Date("2026-10-01") is read as midnight UTC, while new Date("2026-10-01T09:00") is read as local time.

The year 2038 problem

Older systems store Unix time as a signed 32-bit number, whose largest value is 2,147,483,647. That's 03:14:07 UTC on 19 January 2038. One second later, the number wraps round to −2,147,483,648, which reads as 20:45:52 UTC on 13 December 1901. Modern systems use 64-bit values, which last for roughly 292 billion years, but 32-bit time can still lurk in old embedded devices, file formats and database columns. Anything that already handles dates beyond 2038, such as a long loan schedule or a certificate expiry date, is where it shows up first.

Converting timestamps with our tools

1. Open the Timestamp Converter. The top shows the current Unix time in seconds and milliseconds, and Copy current timestamp copies the seconds value.
2. Under Timestamp → date, paste the number into Timestamp. Commas, spaces and underscores are ignored. With Unit left on Detect automatically, up to 11 digits are read as seconds, 12 to 14 as milliseconds, 15 to 17 as microseconds and longer numbers as nanoseconds. For small values near 1970, choose the unit yourself.
3. Pick a zone in Show in time zone. The list holds your device's zone alongside 16 common ones. You get the time there, in UTC, in ISO 8601 and RFC 2822 (email) formats, a relative time such as "in 3 months", and the value in seconds and milliseconds.
4. Under Date → timestamp, set Date and time and Time zone, then read Unix time (seconds), Milliseconds and UTC. The Check row converts the result back. If it shows a different clock time from the one you typed, your time fell in a daylight-saving gap. For a repeated hour it picks one of the two instants, so check the zone label in that row to see which one you got.
5. For durations, use the Date Difference Calculator, which shows years, months and days plus totals in weeks, days, hours, minutes and seconds (tick Include the end day (add 1 day) if both dates count). The Date Calculator counts the days between two dates or adds days to a start date when you click Calculate.

Everything runs in your browser, and the zone rules come from your browser too, so a browser that hasn't been updated in a long time may miss a recent rule change. For a zone that isn't in the list, convert to UTC and apply that zone's offset.

Quick answers

• Is a timestamp different in each country? No. The number is the same worldwide; only the local clock time differs.
• How do I get the current timestamp in code? JavaScript: Math.floor(Date.now() / 1000). Python: int(time.time()). Linux or macOS terminal: date +%s.
• Why is my converted time off by a whole number of hours? Usually a wrong zone, a missed daylight-saving change, or a local time that was treated as UTC.
• Why does my date show 1970? Seconds were given to something that expects milliseconds. Multiply by 1,000.
• Does Unix time include leap seconds? No. Every day counts as 86,400 seconds.
• Scheduling jobs? Cron schedules are written in clock time rather than timestamps, so the same zone questions apply. See cron expressions explained.

Spotted a mistake or something out of date? Tell us and we'll fix it.