Unix Timestamp Converter

What is a Unix timestamp?

A Unix timestamp is the count of seconds that have passed since 00:00:00 UTC on 1 January 1970, a moment called the Unix epoch. 0 is that exact second, 1700000000 is 14 November 2023 at 22:13:20 UTC, and negative numbers are dates before 1970.

The idea comes from the Unix operating system and is written into the POSIX standard as "Seconds Since the Epoch". It's popular because a single integer is easy to store, sort, compare and subtract. The gap between two events is just one number minus another, with no calendars involved.

• It has no time zone. A unix epoch timestamp names the same instant everywhere on Earth. Time zones only matter when you turn it into a wall-clock date.
• Every day is exactly 86,400 seconds. POSIX says each day is accounted for by exactly 86,400 seconds, so leap seconds are not counted. When a leap second happens, Unix time repeats or skips a second instead.
• It's usually an integer. Most systems store whole seconds, but many (JavaScript, Java) use milliseconds, and databases and logs often use microseconds or nanoseconds.

How to convert a Unix timestamp to a date and back

To convert a Unix timestamp to time, split it into whole days and leftover seconds, then count calendar days forward from 1 January 1970. The tool above does this instantly, but doing it once by hand shows what's going on.

1. Take 1700000000 and divide by 86,400. That gives 19,675 whole days and 80,000 seconds left over.
2. Turn the leftover seconds into a time of day: 80,000 seconds is 22 hours, 13 minutes and 20 seconds.
3. Count 19,675 days forward from 1970-01-01, allowing for leap years. You land on 2023-11-14.
4. Put them together: 2023-11-14 22:13:20 UTC. Apply a time zone offset only now, for example −5 hours for New York in November gives 17:13:20 local time.

To convert to Unix timestamp from a date, run the steps in reverse: count the days from 1970 to your date, multiply by 86,400 and add the seconds since midnight. The catch is that your date must be in UTC first. If you only know the local time, subtract the zone's offset for that exact date, which changes with daylight saving time.

Seconds, milliseconds, microseconds or nanoseconds?

You can tell the unit by counting digits: a current date is 10 digits in seconds, 13 in milliseconds, 16 in microseconds and 19 in nanoseconds. This Unix timestamp converter uses that rule to pick the unit automatically and tells you what it assumed, so a 13-digit JavaScript value doesn't turn into a date 50,000 years from now.

Auto-detection treats up to 11 digits as seconds, 12 to 14 as milliseconds, 15 to 17 as microseconds and 18 or more as nanoseconds. That's right for any date between roughly 1973 and 5138. For older dates or tiny test values, such as 86400, set the Unit menu by hand. When you override it, the badge says which unit the number looked like, so a mismatch is obvious.

Time zones and daylight saving time

A Unix timestamp is always UTC, so time zones only apply when you display it or when you convert time to Unix timestamp from a local date. This unix timestamp converter reads the full list of IANA zones from your browser, so you can search names like America/Sao_Paulo, Asia/Kathmandu (UTC+05:45) or Australia/Lord_Howe.

Daylight saving time creates two awkward cases when you go from a local date to a timestamp:

Skipped times

When clocks spring forward, a local time like 02:30 on 10 March 2024 in New York never happens. The converter moves it forward by the gap (to 03:30 EDT) and tells you it did.

Repeated times

When clocks fall back, 01:30 on 3 November 2024 in New York happens twice, an hour apart. The converter shows the first one and gives you the second timestamp too.

This follows the same "compatible" rule that JavaScript's Date and the newer Temporal API use, so results match what most code will do. The zone maths comes from your browser's own time zone database, so historical rule changes are included as far back as that database goes.

ISO 8601, RFC 2822 and other output formats

Going from Unix to timestamp strings people can read is the main job, so every unix timestamp conversion here shows the instant in the formats developers paste most often, each with a copy button.

ISO 8601 / RFC 3339

2023-11-14T22:13:20.000Z. The safest format for APIs, JSON and databases. The zone version adds the offset, e.g. -05:00. Microsecond and nanosecond inputs keep their extra digits.

RFC 2822

Tue, 14 Nov 2023 22:13:20 +0000. The email Date: header format, now defined by RFC 5322.

HTTP date

Tue, 14 Nov 2023 22:13:20 GMT. The format RFC 9110 requires in headers like Last-Modified and Expires.

Readable and relative

A full date in words for your locale, plus "3 hours ago" style relative time, day of week and ISO week number.

How to get and convert Unix time in code

Every major language can read the current Unix timestamp and convert from Unix timestamp to a date in one line. These snippets return seconds unless noted, and all use UTC so the output doesn't depend on the server's zone.

Going the other way, to convert a date to Unix timestamp, parse the date as UTC and read its seconds:

// JavaScript
Math.floor(Date.parse("2023-11-14T22:13:20Z") / 1000)   // 1700000000

# Python
datetime(2023, 11, 14, 22, 13, 20, tzinfo=timezone.utc).timestamp()

// Java
Instant.parse("2023-11-14T22:13:20Z").getEpochSecond()

// Go
time.Date(2023, 11, 14, 22, 13, 20, 0, time.UTC).Unix()

-- PostgreSQL
SELECT extract(epoch FROM timestamptz '2023-11-14 22:13:20+00');

# Bash (macOS; on Linux use: date -u -d "2023-11-14 22:13:20" +%s)
date -u -j -f "%Y-%m-%d %H:%M:%S" "2023-11-14 22:13:20" +%s

For milliseconds, use Date.now() in JavaScript, time.time_ns() // 1_000_000 in Python, System.currentTimeMillis() in Java and time.Now().UnixMilli() in Go. If you're debugging API responses full of timestamps, the JSON Formatter makes them easier to find, and the Base64 decoder opens JWT payloads so you can read their exp claims.

What is the year 2038 problem?

The year 2038 problem is the moment a signed 32-bit Unix timestamp runs out: the largest value, 2,147,483,647, is 19 January 2038 at 03:14:07 UTC. One second later a 32-bit counter wraps to −2,147,483,648, which reads as 13 December 1901.

Most modern systems already use a 64-bit time_t, which lasts for about 292 billion years. The risk is in old embedded devices, file formats and database columns that still hold 32 bits, such as MySQL's TIMESTAMP type, whose documented range ends at 2038-01-19 03:14:07 UTC. Paste 2147483648 above to see the boundary.

The converter itself handles anything JavaScript's Date can hold: 100 million days either side of 1970, which covers the years 271821 BC to 275760 AD. Values outside that range get a clear error instead of a wrong date.

What this epoch unix timestamp converter does differently

It does the whole job in one place and keeps your data on your device. Most epoch converter pages handle one direction and one unit; this one covers both directions, four units, every zone and whole lists.

• Live current Unix timestamp in seconds and milliseconds, with pause and copy, so you can grab a fixed value.
• Unit detection you can see and override. No silent guessing about milliseconds.
• Exact precision. 19-digit nanosecond values are handled as big integers, so the last digits aren't rounded away.
• Honest daylight saving handling. Skipped and repeated local times are flagged, not hidden.
• Batch mode. Convert unix timestamp lists from logs or spreadsheets, then download a CSV with UTC and zone columns.
• Date strings too. Paste ISO 8601 or RFC 2822 text to get a timestamp without filling in a form.
• Shareable links. Add ?ts=1700000000 to the page address to open the converter with that value filled in.

Need to compare two log files after converting them? Use the Diff Checker, or see JSON formatter extensions. For a browser toolbar setup, see our picks of Chrome extensions for developers, including a JSON viewer extension that makes raw API timestamps readable in the tab.