Unix timestamp converter

What is Unix time?

Unix time, also called epoch time or POSIX time, is a way of writing a moment as a single number: the count of seconds that have passed since 00:00:00 UTC on 1 January 1970. The timestamp 0 is that midnight, 86400 is the same time on 2 January 1970, and a timestamp of 1794571200 is noon UTC on 13 November 2026. Because the number is just a count, it carries no time zone, no daylight saving rule and no calendar. Everyone who has the same timestamp is pointing at the same instant, wherever they are.

That simplicity is why almost every operating system, database, programming language and web API stores times this way. Adding an hour is adding 3600. Finding how long something took is a subtraction. Sorting events is sorting integers. The conversion to a human date, with its months, leap years and time zones, only happens at the last step, when a person needs to read it. The converter above does that last step for you, in UTC, in your own time zone and in any other IANA zone you choose.

The epoch: 1 January 1970

The starting point is called the epoch. The first Unix systems at Bell Labs counted time in sixtieths of a second from the start of 1971, and the designers later moved the origin to 1 January 1970 and switched to whole seconds, because it gave a rounder, more useful range. The date has no deeper meaning, but it has stuck: JavaScript, Python, PHP, Java, Go, Rust, MySQL, PostgreSQL and the Linux kernel all agree on it. Other systems use different origins. Windows file times start in 1601, Excel serial dates in 1900, and GPS time in 1980, so a number from those systems must be converted before it can be treated as a Unix timestamp.

Seconds, milliseconds and microseconds

Not every system counts in seconds. Classic Unix, Python’s time.time(), PHP’s time() and most databases use seconds, which gives a ten-digit number today. JavaScript’s Date.now() and Java’s System.currentTimeMillis() use milliseconds, a thirteen-digit number. Some tracing tools and databases store microseconds (sixteen digits) or nanoseconds (nineteen digits). The converter guesses the unit from the number of digits: up to 11 digits is read as seconds, 12 to 14 as milliseconds, 15 to 17 as microseconds and anything longer as nanoseconds. A thirteen-digit number pasted from a browser console is therefore read correctly without any setting.

The most common mistake is mixing the two. Passing a seconds value to JavaScript’s Date constructor gives a date in January 1970, and passing milliseconds to a function that expects seconds gives a year more than fifty thousand years in the future. If a date looks absurdly early or late, check the unit first.

Leap seconds: what Unix time ignores

UTC occasionally adds a leap second to keep clocks in step with the Earth’s slightly irregular rotation. Twenty-seven have been added since 1972, the most recent at the end of 31 December 2016. Unix time does not count them. It defines every day as exactly 86,400 seconds, so when a leap second occurs the timestamp either repeats a value or, on many modern systems, is smeared across several hours so that no value repeats. The practical consequence is that the difference between two Unix timestamps is not always the true number of elapsed seconds, but for ordinary logging, scheduling and date maths the error is invisible. In 2022 the international standards body agreed to stop adding leap seconds by 2035, which will remove the issue.

The year 2038 problem

Many older systems store Unix time in a signed 32-bit integer. The largest value such a field can hold is 2147483647, which is 03:14:07 UTC on 19 January 2038. One second later the counter overflows and wraps to −2147483648, which software reads as 20:45:52 UTC on 13 December 1901. Anything that uses 32-bit time, such as old embedded devices, some file formats and legacy databases, can then fail or produce wildly wrong dates, in the same way that the Year 2000 bug threatened two-digit years.

The fix is to use a 64-bit integer, which will not overflow for about 292 billion years, and modern operating systems and languages already do. The risk lies in systems that are hard to update, and in data that is stored with a 32-bit field. Unsigned 32-bit fields buy more time, until 06:28:15 UTC on 7 February 2106, but they cannot represent dates before 1970.

Timestamps and time zones

A Unix timestamp is always UTC. A date and time written without a zone, such as 2026-11-13 09:00, is not a timestamp until you say where it was measured. The second tool above takes a date, a time and a zone and works out the correct instant, including daylight saving: 9:00 AM on 13 November 2026 in New York is 1794578400, while the same wall-clock time in Kolkata is 1794540600. If you store timestamps and show them in the viewer’s time zone, you avoid almost all daylight saving bugs. Convert the other way, from local text to a timestamp, as early as possible, and always record the zone you used. For help with the offsets themselves, see our time difference calculator and the list of time zone converters.

Converting timestamps in code

Every language has a one-line way to get the current timestamp and convert it back. Here are the ones people look up most often.

JavaScript

Date.now()                       // milliseconds since the epoch
Math.floor(Date.now() / 1000)    // seconds since the epoch
new Date(ts * 1000)              // Date from a seconds timestamp
new Date(ts * 1000).toISOString()  // "2023-11-14T22:13:20.000Z" for 1700000000

Python

import time
from datetime import datetime, timezone

time.time()                                # seconds, as a float
datetime.fromtimestamp(ts, tz=timezone.utc)  # aware datetime in UTC
datetime(2026, 11, 13, 12, tzinfo=timezone.utc).timestamp()

SQL

-- MySQL
SELECT FROM_UNIXTIME(1700000000);
SELECT UNIX_TIMESTAMP('2026-11-13 12:00:00');

-- PostgreSQL
SELECT to_timestamp(1700000000);
SELECT extract(epoch FROM now());

-- SQLite
SELECT datetime(1700000000, 'unixepoch');
SELECT strftime('%s', 'now');

MySQL’s UNIX_TIMESTAMP interprets a plain date in the session time zone, so set it to UTC if you want the result to match the converter on this page.

Excel and Google Sheets

=(A1/86400)+DATE(1970,1,1)         timestamp in seconds to a date (format the cell as date and time)
=(A1-DATE(1970,1,1))*86400         date back to a timestamp in seconds
=(A1/86400000)+DATE(1970,1,1)      same, for a milliseconds timestamp

Notable timestamps

A few values come up often in tutorials, tests and bug reports. All times are UTC.