Unix Timestamp Converter

Convert epoch timestamps to dates and dates to timestamps — seconds to nanoseconds

What Is a Unix Timestamp?

A Unix timestamp, also called epoch time or POSIX time, is the number of seconds that have passed since January 1, 1970 at 00:00:00 UTC. That moment is the Unix epoch. Timestamp 0 is the epoch itself, 1700000000 is November 14, 2023 at 22:13:20 UTC, and negative numbers count backwards into the 1960s and earlier.

Programmers use timestamps because one integer is easy to store, sort, compare, and do arithmetic on. Subtracting two timestamps gives you a duration in seconds. Adding 86,400 moves you forward exactly one day. And because the count starts from a fixed moment in UTC, the number doesn’t depend on any time zone.

This converter works in both directions: paste a timestamp to get a readable date, or paste a date to get its timestamp. For a gentler introduction, read our guide Understanding Unix Timestamps.

How to Use the Timestamp Converter

  1. Paste a timestamp or a date into the input. Timestamps can be in seconds, milliseconds, microseconds, or nanoseconds, with an optional minus sign or decimal fraction (1700000000.5). Dates can be ISO 8601 (2023-11-14T22:13:20Z) or plain English (November 14, 2023).
  2. Press Convert or Ctrl+Enter. The result shows the timestamp in seconds and milliseconds, the date in UTC, ISO 8601, and your local time zone, how long ago (or how far ahead) it is, and a year/month/day/time breakdown in local time.
  3. Click Current Timestamp to load the current Unix time. If you have no saved input, the converter shows it as soon as the page opens.
  4. Copy the result with the Copy button or Ctrl+Shift+C, and clear the input with Ctrl+L.

How the Converter Detects Seconds, Milliseconds, and Nanoseconds

Different systems count time in different units, and the raw number doesn’t say which one it uses. The converter reads the number of digits in the integer part and picks the unit that gives a sensible date. The unit it chose is printed as the first line of the result.

DigitsRead asExampleTypical source
up to 11Seconds1700000000Unix tools, PHP, Python, JWT, most APIs
12–14Milliseconds1700000000000JavaScript, Java, Kafka, Elasticsearch
15–17Microseconds1700000000000000Go UnixMicro(), BigQuery UNIX_MICROS()
18–19Nanoseconds1700000000000000000Go UnixNano(), Python time.time_ns(), InfluxDB, OpenTelemetry

Any plain number is treated as a timestamp, so 0, 86400, and -86400 (the last day of 1969) all work. To convert a year, type a full date like 2023-01-01 instead of 2023. Nanosecond input is read as a digit string, so a 19-digit value keeps its precision, and the result is shown to the millisecond.

Time Zones: Why a Converted Date Can Be Hours Off

A timestamp is one instant. Time zones only matter when you turn that instant into a calendar date, or when you parse a date string that doesn’t say which zone it’s in. That second case is where most off-by-a-few-hours bugs come from. JavaScript, and this converter, follow the ECMAScript rules:

  • 2023-11-14 (a date with no time) is read as midnight UTC.
  • 2023-11-14T22:13:20 (a date and time with no offset) is read as your local time.
  • 2023-11-14T22:13:20Z or 2023-11-14T22:13:20+02:00 is unambiguous.

When the converter applies one of the first two rules, it says so in the result. Most other languages give no such warning. Python’s datetime.timestamp() assumes local time for a naive datetime, and MySQL’s FROM_UNIXTIME() formats in the session time zone. If you need a portable value, always include Z or an explicit offset.

Common Timestamp Mistakes

  • A date in the year 55,000. You passed milliseconds to something that expects seconds. Python fails outright with ValueError: year 55840 is out of range. Divide by 1000.
  • A date in January 1970. The opposite mistake: seconds passed where milliseconds are expected. new Date(1700000000) in JavaScript gives January 20, 1970. Multiply by 1000.
  • A month that’s off by one. JavaScript’s getMonth() counts from 0, so November is 10. The converter’s breakdown shows the calendar month number (11) and its name.
  • Naive UTC datetimes in Python. datetime.utcfromtimestamp() returns a datetime with no time zone attached, which later code easily treats as local time. It’s deprecated since Python 3.12. Use datetime.fromtimestamp(ts, tz=timezone.utc).
  • Lost nanosecond precision. JavaScript numbers are exact only up to 9,007,199,254,740,991 (16 digits). JSON.parse turns the nanosecond value 1700000000123456789 into 1700000000123456800. Send 19-digit timestamps as strings, or parse them with BigInt.
  • Milliseconds in a 32-bit column. A millisecond timestamp doesn’t fit a 32-bit INT. Use BIGINT, or a native timestamp type.

Get and Convert Timestamps in Code

LanguageCurrent time (seconds)Timestamp → date
JavaScriptMath.floor(Date.now() / 1000)new Date(ts * 1000)
Pythonint(time.time())datetime.fromtimestamp(ts, tz=timezone.utc)
PHPtime()gmdate('c', $ts)
JavaInstant.now().getEpochSecond()Instant.ofEpochSecond(ts)
Gotime.Now().Unix()time.Unix(ts, 0).UTC()
C#DateTimeOffset.UtcNow.ToUnixTimeSeconds()DateTimeOffset.FromUnixTimeSeconds(ts)
PostgreSQLEXTRACT(EPOCH FROM now())to_timestamp(ts)
MySQLUNIX_TIMESTAMP()FROM_UNIXTIME(ts)
Shell (Linux)date +%sdate -u -d @ts
Shell (macOS)date +%sdate -u -r ts

To go the other way, from a date to a timestamp, parse the date with an explicit zone and read its epoch value: Date.parse('2023-11-14T22:13:20Z') / 1000 in JavaScript, Instant.parse(...).getEpochSecond() in Java, strtotime('2023-11-14 22:13:20 UTC') in PHP.

The Year 2038 Problem

Many older systems store Unix time in a signed 32-bit integer. Its maximum value, 2,147,483,647, is January 19, 2038 at 03:14:07 UTC. One second later the counter overflows to −2,147,483,648, and the date jumps back to December 13, 1901.

Modern operating systems and languages use a 64-bit time value, which lasts about 292 billion years. The risk that’s left sits in 32-bit embedded devices, old binary file formats, and database columns. MySQL’s TIMESTAMP type, for example, still ends at 2038-01-19 03:14:07 UTC. Anything that schedules dates far in advance, like 30-year loans or 20-year root certificates, hits the limit first. Paste 2147483647 into the converter to see the exact cutoff.

Unix Timestamps vs ISO 8601 Dates

Unix timestampISO 8601 string
Example17000000002023-11-14T22:13:20Z
Human-readableNoYes
Time zoneAlways UTC by definitionExplicit offset, or ambiguous if omitted
SortingNumeric, always correctCorrect only with the same format and offset
Size4–8 bytes as an integer20+ characters
PitfallSeconds vs millisecondsMissing offset

Use timestamps where a spec requires them or where you compare and sort a lot. Use ISO 8601 (or its stricter profile, RFC 3339) in APIs and config files that people read. Either way, store instants in UTC and convert to local time only when you display them.

Where You’ll Run Into Unix Timestamps

  • JWTs. The exp, iat, and nbf claims are seconds since the epoch. Decode a token with the JWT Decoder, then paste exp here to see exactly when it expires.
  • API responses and headers. Stripe’s created fields and GitHub’s x-ratelimit-reset header are Unix seconds. Slack message IDs like 1700000000.123456 are seconds with a microsecond fraction, which the converter reads directly.
  • Logs and schedulers. Servers, queues, and observability tools stamp events in seconds, milliseconds, or nanoseconds. Pair the converter with the Cron Expression Builder when you’re checking when a job ran against when it was scheduled.
  • IDs with a clock inside. A MongoDB ObjectId starts with a 4-byte Unix timestamp in hex: convert its first 8 hex characters with the Number Base Converter and paste the decimal here. UUIDv7 and ULID put a millisecond timestamp in their first 48 bits.

Your Data Stays in Your Browser

The converter runs entirely in JavaScript in your browser. Nothing you paste is uploaded or logged. That matters when the timestamp comes from a production log line or a token claim you’d rather not paste into a random website.

Frequently Asked Questions

What is a Unix timestamp?

A Unix timestamp (also called epoch time or POSIX time) is the number of seconds that have passed since the Unix epoch, January 1, 1970 at 00:00:00 UTC. A timestamp of 0 is that exact moment, 1700000000 is November 14, 2023 at 22:13:20 UTC, and negative values are dates before 1970. Because it's a single number with no time zone attached, it's the standard way to store and compare points in time in databases, APIs, and logs.

How do I convert a Unix timestamp to a date?

Paste the timestamp into the converter above and press Ctrl+Enter. You get the date in UTC, ISO 8601, and your local time zone. In code, use new Date(ts * 1000) in JavaScript, datetime.fromtimestamp(ts, tz=timezone.utc) in Python, or date -u -d @ts on Linux (date -u -r ts on macOS).

How do I know if a timestamp is in seconds or milliseconds?

Count the digits. For present-day dates, a timestamp in seconds has 10 digits, milliseconds 13, microseconds 16, and nanoseconds 19. This converter detects the unit from the digit count and prints the unit it used as the first line of the result, so you can see when it guessed differently from what you expected.

Why does my timestamp convert to 1970 or to the year 55,000?

The unit is wrong. A date in January 1970 means a seconds value was read as milliseconds: 1700000000 milliseconds is only about 20 days after the epoch. A year in the 50,000s means a milliseconds value was read as seconds. Divide by 1000 or multiply by 1000 to fix it, or paste the raw number here and let the converter detect the unit.

Is a Unix timestamp the same in every time zone?

Yes. A Unix timestamp counts seconds from a fixed moment in UTC, so the same instant has the same timestamp in Tokyo, London, and New York. Time zones only come into play when you format the timestamp as a calendar date. If a converted date looks a few hours off, the formatting step used a different time zone than you expected, not the timestamp.

Does Unix time count leap seconds?

No. Unix time treats every day as exactly 86,400 seconds and ignores the 27 leap seconds added since 1972. That keeps date arithmetic simple: midnight UTC is always a multiple of 86,400. The trade-off is that a leap second has no unique timestamp of its own.

What is the Year 2038 problem?

A signed 32-bit integer can hold timestamps up to 2,147,483,647, which is January 19, 2038 at 03:14:07 UTC. One second later it overflows to a negative number and the date jumps back to December 13, 1901. Systems with a 64-bit time value are safe for billions of years. The risk is in 32-bit embedded devices, old file formats, and database columns that store time as a 32-bit integer.

Is my data safe?

Yes. Every conversion runs in your browser with JavaScript. No timestamp or date is sent to a server. Your last input is kept in your browser's local storage so it's still there after a reload. Click Clear or press Ctrl+L to remove it.