Commas, spaces and underscores are ignored.

When converting a date to a timestamp, this is also the zone the date and time are read in.

How Unix timestamps work

A Unix timestamp counts the seconds elapsed since midnight UTC on 1 January 1970, known as the Unix epoch. Because it is a single number tied to UTC, it identifies one instant unambiguously — no time zone, no daylight saving, no date format to misread.

Units and the digit-count trick

The same instant can be expressed in seconds, milliseconds, microseconds or nanoseconds, and confusing them is the most common bug in date-handling code. For dates in the current era:

  • 10 digits — seconds. Used by Unix, PHP and most APIs.
  • 13 digits — milliseconds. Used by JavaScript and Java.
  • 16 digits — microseconds. Used by Python's datetime and PostgreSQL.
  • 19 digits — nanoseconds. Used by Go and by some time-series databases.

The unit is detected from magnitude, and the result always states which one was applied. You can override it if you are working with a historic date where the digit count is ambiguous.

Negative timestamps

Dates before 1970 are represented as negative numbers: −86400 is 31 December 1969. Not every system handles these correctly, so test carefully if you are storing historic dates.

The Year 2038 problem

A signed 32-bit integer runs out at 2,147,483,647 seconds, which is 03:14:07 UTC on 19 January 2038. Systems still storing time in 32 bits will wrap round to 1901. Most current systems use 64-bit values, which are good for roughly 292 billion years.

Leap seconds

Unix time treats every day as exactly 86,400 seconds and ignores leap seconds entirely. It is therefore not a true count of elapsed SI seconds since 1970 — it is a count of days multiplied out, which is precisely what makes the arithmetic tractable.

Worked example

Timestamp 1767225600

  • Ten digits, so it is a seconds timestamp.
  • 1767225600 ÷ 86,400 = 20,454 whole days since the epoch.
  • That lands on 1 January 2026, 00:00:00 UTC.
  • In London that is also 00:00 on 1 January, because the UK is on GMT in January.
  • In New York it is still 19:00 on 31 December 2025.

Reference points

Landmark Seconds Meaning
Unix epoch 0 1 January 1970, 00:00:00 UTC
Signed 32-bit overflow 2,147,483,647 19 January 2038 — the "Year 2038 problem" for 32-bit signed timestamps
Signed 32-bit minimum -2,147,483,648 13 December 1901 — the earliest date a 32-bit signed timestamp can hold
One billion seconds 1,000,000,000 9 September 2001
Two billion seconds 2,000,000,000 18 May 2033

Frequently asked questions

Is my timestamp in seconds or milliseconds?

Count the digits. A current timestamp in seconds has 10 digits, milliseconds has 13, microseconds 16 and nanoseconds 19. The converter detects this automatically and always tells you which unit it used, so a misread number cannot silently produce a date in 1970 or in the year 57000.

What is the Unix epoch?

Midnight UTC on 1 January 1970. A Unix timestamp is simply the number of seconds elapsed since that moment, which is why it is also called epoch time or POSIX time.

What is the Year 2038 problem?

A signed 32-bit integer can hold at most 2,147,483,647, which as a seconds timestamp is 03:14:07 UTC on 19 January 2038. Systems still using 32-bit time will overflow to a negative number and read the date as 1901. Most modern systems use 64-bit values and are unaffected.

Do timestamps have a time zone?

No, and this is the point of them. A timestamp identifies a single instant, the same everywhere. A time zone is only applied when you display it, which is why the result shows the UTC reading and a local reading side by side.

Are leap seconds included?

No. Unix time deliberately ignores leap seconds, treating every day as exactly 86,400 seconds. This keeps the arithmetic simple but means Unix time is not a true count of elapsed SI seconds since 1970.