Guides Pricing

Guide

Unix time explained: epoch, milliseconds, and timezones

What a Unix timestamp is, how seconds vs milliseconds differ, how timezones fit in, and the 2038 problem — with a live converter to follow along.

Try it — Unix Timestamp Converter
Unix Timestamp Converter
Timezone
Unix (seconds)
Unix (seconds)
no matches
Unix (milliseconds)
ISO 8601
UTC
Local
RFC 2822
Relative
Day of week
Enter a timestamp or date, or hit "Now"

If you have ever seen a value like 1700000000 in a log line, an API response, or a database column and wondered what date it represents, you have met Unix time. It is the most common way software stores a moment in time. Paste any timestamp into the converter above to turn it into a readable date as you read.

What a Unix timestamp actually is

A Unix timestamp is a single number: the count of seconds since the Unix epoch, which is midnight UTC on 1 January 1970. So 0 is the epoch itself, 60 is one minute after it, and 1700000000 is 14 November 2023, 22:13:20 UTC.

Storing time as one integer is appealing because it is compact, easy to compare (later moments are simply larger numbers), and free of timezone ambiguity — the count is always measured from UTC.

Seconds vs milliseconds

The single most common source of confusion is the unit:

  • Seconds — the classic Unix timestamp. Today's values are 10 digits (around 1.7 billion).
  • Milliseconds — 1000× larger, 13 digits. JavaScript's Date.now() and many web APIs use this.

A quick rule of thumb: a 10-digit number is seconds, a 13-digit number is milliseconds. To convert milliseconds to seconds, divide by 1000. The converter above detects which one you pasted and shows both, so you never have to guess.

Where timezones come in

Because a timestamp is counted from the UTC epoch, the timestamp itself has no timezone. The same instant is the same number in Tokyo and in New York. Timezones only appear when you format the timestamp into a human date — that is when "22:13 UTC" becomes "17:13 in New York". The converter shows the UTC value and a timezone-adjusted local value side by side so the difference is obvious.

The year 2038 problem

Older systems stored the timestamp in a signed 32-bit integer, which can only count up to 2,147,483,647 — a value reached on 19 January 2038. Past that point the number overflows and wraps to a negative value, mis-reading the date as 1901. The fix is simply to store the timestamp as a 64-bit integer, which pushes the limit hundreds of billions of years into the future. Most modern languages and databases already do this, but it is worth checking on legacy systems.

Try it

Paste a timestamp (in seconds or milliseconds) or a date into the tool above to convert between the two. It is handy for reading log timestamps, checking token and cookie expiry, and turning API epoch fields into dates you can actually read.

Frequently asked questions

It is the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970 (the "epoch"), not counting leap seconds. It is a single integer that represents a moment in time independent of any timezone.
A 10-digit value is seconds since the epoch; a 13-digit value is milliseconds. JavaScript's Date.now() returns milliseconds, while most Unix tools and databases use seconds. Divide milliseconds by 1000 to get seconds.
No. A timestamp is always counted from the UTC epoch, so the same instant has the same timestamp everywhere. Timezones only matter when you format the timestamp into a human-readable date.
Systems that store the timestamp as a signed 32-bit integer overflow on 19 January 2038, when the value exceeds 2,147,483,647. The fix is to store the timestamp as a 64-bit integer, which most modern systems already do.
Paste the timestamp into the converter above. It detects seconds vs milliseconds automatically and shows the date in UTC, your chosen timezone, ISO 8601, and RFC 2822 form.

Related

Esc
↑↓ navigate open Esc close