Menu

Unix time now

1793707509

Milliseconds
1793707509423
Microseconds
1793707509000000
Nanoseconds
1793707509000000000
UTC (ISO 8601)
2026-11-03T12:05:09Z

Seconds since 1970-01-01 00:00:00 UTC, counted from our server’s clock, not your device’s.

Timestamp to date

Date to timestamp

Seconds to days, hours and minutes

1 day

Unix time in code

Current timestamp, timestamp to date, and date to timestamp, in UTC. The examples use 1793622375 (2026-11-02T12:26:15Z); convert another value above and they follow it.

Current Unix time

Math.floor(Date.now() / 1000)

Timestamp to date

new Date(1793622375 * 1000).toISOString()

Date to timestamp

Date.parse('2026-11-02T12:26:15Z') / 1000

Date works in milliseconds; divide by 1000 for seconds.

What Unix time counts, exactly

POSIX defines the epoch as “zero hours, zero minutes, zero seconds, on January 1, 1970 Coordinated Universal Time” and counts every day as exactly 86,400 seconds. A Unix timestamp is therefore a calendar calculation, not a stopwatch: take the UTC date and time, count the days since 1970 times 86,400, and add the seconds of the day.

That has three consequences worth knowing:

Seconds, milliseconds, microseconds, nanoseconds

Unix time is defined in seconds, but many systems store finer units: JavaScript’s Date.now() and Java’s System.currentTimeMillis() give milliseconds, PostgreSQL stores microseconds, Go’s UnixNano() nanoseconds. Mixing them up is the most common timestamp bug: a millisecond value read as seconds lands tens of thousands of years in the future, and a seconds value read as milliseconds lands in January 1970. The digit count tells you which you have: 10 digits for seconds, 13 for milliseconds, 16 for microseconds and 19 for nanoseconds, for any date between 2001 and 2286.

The year 2038 problem

A signed 32-bit integer holds at most 2,147,483,647. As a Unix timestamp that is 2038-01-19T03:14:07Z. One second later, a 32-bit counter wraps to -2,147,483,648, which reads as 1901-12-13T20:45:52Z. Unsigned 32-bit values last until 2106-02-07T06:28:15Z. The POSIX rationale for time() says it plainly: a 32-bit signed integer “fails in the year 2038”, and the preferred solution is a wider time_t. The current standard (Issue 8, 2024) requires time_t to be at least 64 bits. The risk is in old embedded systems, file formats and database columns that still store 32 bits (SQL Server’s DATEADD, for example, takes an int).

Other counts that start somewhere else

Much software counts from another zero. Choose the format in the converter’s Unit list to read one, and any timestamp you convert shows all of these.

FormatCountsFromFrom Unix seconds
.NET DateTime.Ticks100 nsJanuary 1, 0001(s + 62135596800) × 10,000,000
Windows FILETIME, Active Directory100 nsJanuary 1, 1601 UTC(s + 11644473600) × 10,000,000
Excel serial datedaysserial 1 is January 1, 1900s ÷ 86,400 + 25569
Discord snowflakems, top bitsthe first second of 2015(ms − 1420070400000) × 222

Microsoft notes that DateTime ticks leave out leap seconds, like Unix time. Excel’s 25569 includes a day that never existed: Microsoft documents that Excel wrongly treats 1900 as a leap year, kept for compatibility with Lotus 1-2-3, so serials before March 1, 1900 are one too high. To show a timestamp in each reader’s own zone in a Discord message, send <t:1793622375:F>; Discord’s docs define the styles.

Milestones

TimestampUTC
1,000,000,0002001-09-09T01:46:40Z
1,500,000,0002017-07-14T02:40:00Z
1,700,000,0002023-11-14T22:13:20Z
1,800,000,0002027-01-15T08:00:00Z
2,000,000,0002033-05-18T03:33:20Z
2,147,483,6472038-01-19T03:14:07Z (signed 32-bit limit)
3,000,000,0002065-01-24T05:20:00Z
4,294,967,2952106-02-07T06:28:15Z (unsigned 32-bit limit)

Unix time at the start of each year

January 1, 00:00:00 UTCSecondsMilliseconds
202417040672001704067200000
202517356896001735689600000
202617672256001767225600000
202717987616001798761600000
202818302976001830297600000
202918619200001861920000000
203018934560001893456000000

A year is 31,536,000 seconds, or 31,622,400 in a leap year, so these differences are exact. The Julian Day also converts with a fixed offset: Unix time = (JD − 2440587.5) × 86,400.

Questions

What is Unix time?
The number of seconds since 00:00:00 UTC on January 1, 1970 (the Unix epoch), counting every day as exactly 86,400 seconds. It is the same number everywhere on Earth at the same instant: time zones only matter when you turn it into a local date and time.
Is a Unix timestamp in UTC?
A timestamp has no time zone; it counts seconds from an instant defined in UTC. Converting it to a date gives a UTC date and time, which you can then show in any zone. A timestamp “in local time” is a bug, usually from building a date in local time and converting it as if it were UTC.
Does Unix time count leap seconds?
No. POSIX defines every day as exactly 86,400 seconds, so the 27 leap seconds inserted into UTC since 1972 are not counted, and Unix time runs behind the true count of elapsed SI seconds by at least that much. POSIX leaves it to each system how its clock gets past a leap second.
Is my timestamp in seconds or milliseconds?
Count the digits. Today a timestamp in seconds has 10 digits, in milliseconds 13, in microseconds 16 and in nanoseconds 19. The converter on this page detects the unit from the length, and you can override it.
What happens in 2038?
Systems that store Unix time in a signed 32-bit integer overflow after 2147483647, which is 2038-01-19T03:14:07Z. The next second wraps to -2147483648, read as 1901-12-13T20:45:52Z. 64-bit time values do not have this problem; POSIX (Issue 8) now requires time_t to be at least 64 bits.
What was Unix time 0?
Thursday, January 1, 1970, 00:00:00 UTC. Negative timestamps count backwards from it; POSIX leaves them undefined, but most languages accept them for dates before 1970.

Related