Menu

Unix timestamp converter: epoch time to date and back

A Unix timestamp is the number of seconds since 1 January 1970 at 00:00:00 UTC, not counting leap seconds. The converter shows the current Unix time and turns any timestamp into a date and time in UTC or your local time, and back.

Current Unix time: 1792713600 seconds since 1 January 1970, 00:00 UTC

Seconds, milliseconds or microseconds; the length decides.

2026-10-23 00:00:00 UTC

More about the result
UTC2026-10-23T00:00:00Z
Your local time
Milliseconds1792713600000
Day of the week (UTC)

What a Unix timestamp counts

Unix time, also called epoch time or POSIX time, counts the seconds since the epoch: 1970-01-01T00:00:00Z. Timestamp 0 is that moment and 86400 is midnight one day later. At 00:00 UTC on 23 October 2026 the count stood at 1792713600.

A timestamp is the same everywhere on Earth at the same moment. Time zones only come in when you turn it into a clock time, so 1792764000 is 14:00 UTC on 23 October 2026, 10:00 in New York (EDT) and 07:00 in Los Angeles (PDT).

POSIX defines every day as exactly 86,400 seconds, so leap seconds are not counted. UTC has had 27 leap seconds since 1972, the last at 23:59:60 on 31 December 2016. During one, a system repeats a timestamp or slows its clock to absorb the extra second; Google and AWS spread it over 24 hours. The result is that subtracting two timestamps gives the elapsed time minus any leap seconds in between.

Seconds, milliseconds and microseconds

Different systems count in different units. Unix tools, PHP and most databases use seconds. JavaScript, Java and many web APIs use milliseconds, and some logs and databases use microseconds. The converter picks the unit from the number of digits.

Unit Digits today 14:00 UTC on 23 October 2026
Seconds 10 1792764000
Milliseconds 13 1792764000000
Microseconds 16 1792764000000000

The 10-digit rule holds from 2001-09-09T01:46:40Z, when the count reached 1,000,000,000, until the year 2286. A timestamp read with the wrong unit gives a date that is obviously off: 1792764000000 read as seconds lands tens of thousands of years in the future, and 1792764000 read as milliseconds lands in January 1970.

Negative timestamps and the year 2038

Dates before 1970 have negative timestamps. -1 is 1969-12-31T23:59:59Z and -86400 is midnight on 31 December 1969. Most modern languages accept them, but some older functions and file formats reject values below zero.

The year 2038 problem comes from storing the count in a signed 32-bit integer. Its largest value, 2147483647, is 2038-01-19T03:14:07Z. One second later the number wraps to -2147483648, which reads as 1901-12-13T20:45:52Z. Current operating systems, languages and databases use 64-bit time, but embedded devices, old file formats and database columns declared as 32-bit integers can still be affected.

Getting and converting Unix time in code

Current time in seconds:

  • JavaScript: Math.floor(Date.now() / 1000) (Date.now() alone gives milliseconds)
  • Python: int(time.time())
  • Shell (Linux and macOS): date +%s
  • MySQL: SELECT UNIX_TIMESTAMP();
  • PostgreSQL: SELECT extract(epoch FROM now());

Timestamp to date:

  • JavaScript: new Date(1792764000 * 1000).toISOString() returns 2026-10-23T14:00:00.000Z
  • Python: datetime.fromtimestamp(1792764000, tz=timezone.utc)
  • GNU date: date -u -d @1792764000; on macOS: date -u -r 1792764000
  • MySQL: SELECT FROM_UNIXTIME(1792764000); (in the session time zone)
  • PostgreSQL: SELECT to_timestamp(1792764000); (returns a timestamp with time zone)

Watch the time zone in each case. Python’s fromtimestamp without tz and MySQL’s FROM_UNIXTIME both convert to local time, which is a common source of results that are off by a few hours. To write the result as text, the ISO 8601 converter explains the Z and offset forms.

Unix time in Excel and Google Sheets

Spreadsheets count days, not seconds, from their own epoch. Divide the timestamp by 86,400 and add the serial number of 1 January 1970, which is 25569 in Excel’s 1900 system:

=A1/86400+DATE(1970,1,1)

Format the cell as a date and time. 1792713600 gives 46318, which is 23 October 2026. For milliseconds, divide by 86400000. The same formula works in Google Sheets and LibreOffice Calc, whose serial numbers match Excel’s for every date after February 1900. The reverse is =(A1-DATE(1970,1,1))*86400. The result is UTC, because spreadsheets have no time zones; add or subtract hours as a fraction of a day (for example -4/24 for EDT). The Excel date converter explains the serial numbers and the 1904 system, which uses a different offset.

How the converter works

The converter reads the timestamp as an exact number of milliseconds and converts it with the same 86,400-second day that POSIX and JavaScript use, so its results match date, Python and browsers. Local time comes from your browser’s time zone settings, including daylight saving time. The day count behind it is the same one used for the Julian Day: the Unix epoch is JD 2440587.5. More detail is on how we calculate.

Questions

What is the current Unix time?

The converter above shows it live, in seconds and milliseconds. At midnight UTC on 23 October 2026 it was 1792713600.

How do I tell seconds from milliseconds?

By length. A timestamp for a date between 2001 and 2286 has 10 digits in seconds, 13 in milliseconds and 16 in microseconds. The converter detects the unit from the number of digits.

Does Unix time count leap seconds?

No. POSIX treats every day as exactly 86,400 seconds, so the 27 leap seconds added since 1972 are not in the count. During a leap second a clock repeats a timestamp or smears the extra second over a longer period.

What happens in 2038?

A signed 32-bit integer can hold timestamps up to 2147483647, which is 2038-01-19 at 03:14:07 UTC. One second later it overflows to a date in December 1901. Systems that store time in 64 bits are not affected.

How do I convert a Unix timestamp in Excel?

With seconds in A1, use =A1/86400+DATE(1970,1,1) and format the cell as a date and time. The result is in UTC. For milliseconds, divide by 86400000 instead.