Skip to main content

Timestamp to Date Converter

English

Timestamp to date

Convert timestamp to human readable date. Supports seconds, milliseconds, and nanoseconds.

In 2038 a 32-bit clock does not reset to 1970 — it lands in 1901

A signed 32-bit timestamp runs out at 2,147,483,647 seconds, which is 03:14:07 UTC on 19 January 2038. The next second does not wrap to zero. It wraps to the most negative value the type can hold, putting the clock at 13 December 1901 — a system that fails this way jumps backwards by 137 years.

How it works

  • Converts a Unix timestamp to a readable date and back, in UTC and local time.
  • Detects whether the input is in seconds or milliseconds, which is the most common mistake.
  • Handles negative timestamps, which are valid and represent dates before 1970.
timestamp = seconds elapsed since 1970-01-01 00:00:00 UTC

32-bit signed maximum = 2,147,483,647 → 2038-01-19 03:14:07 UTC
  the next second wraps to −2,147,483,648 → 1901-12-13 20:45:52 UTC

64-bit signed maximum ≈ 9.223 × 10¹⁸ seconds — roughly 292 billion years

Worked example

The same ten-digit value read two ways, plus the boundary that ends 32-bit time.

  1. 1770000000 read as seconds → 2026-02-02
  2. 1770000000 read as milliseconds → 1970-01-21
  3. 10 digits means seconds; 13 digits means milliseconds
  4. 2147483647 → 2038-01-19 03:14:07 UTC
  5. one second later → 1901-12-13 20:45:52 UTC

The unit error is the dangerous one because it fails quietly. Reading milliseconds as seconds lands you in the year 58,000 and is obvious on sight; reading seconds as milliseconds lands you in January 1970, which looks like a plausible date and passes review.

Reading the result

  • A date of 1 January 1970 in production almost always means a null or zero reached the formatter rather than a real timestamp. The epoch is the default value of an uninitialised integer, which is why that date appears so often in bug reports.
  • Negative timestamps are entirely valid and represent dates before 1970 — −86,400 is 31 December 1969. Systems that reject them cannot store historical dates, which is a real limitation rather than a safety measure.
  • The timestamp itself carries no time zone; it is an absolute count of seconds. The zone enters only at formatting, which is why the same value renders as two different calendar dates for two users and why storing local time instead of a timestamp causes so much grief.
  • Unix time ignores leap seconds by definition, repeating or stretching a second rather than counting it. It is therefore not a true count of elapsed SI seconds, which matters for precise interval measurement and almost never for anything else.

Common questions

Why does my date show as 1970?
Because the value reaching the formatter was zero or null, and zero is the epoch. It is rarely a formatting bug — the timestamp was never set, or was lost somewhere upstream, and 1 January 1970 is what an unset integer looks like once rendered.
How do I tell seconds from milliseconds?
Count the digits. Contemporary timestamps are 10 digits in seconds and 13 in milliseconds. Treating seconds as milliseconds is the error worth guarding against, because it produces a date in early 1970 that looks real rather than an obviously absurd one.

Guide to Unix time

Unix time (epoch time) is a system for storing dates and times as the number of seconds or milliseconds that have elapsed since midnight January 1, 1970 (UTC). This standard is widely used in programming, databases, and network protocols due to its simplicity and ease of date comparison. A value of 0 represents exactly that date, each subsequent second adds 1 to the counter.

Different timestamp formats

The most common format is Unix in seconds (e.g. 1704067200), used in Linux and PHP systems. The second popular format is Unix in milliseconds (e.g. 1704067200000), used in JavaScript and JVM. The third is in nanoseconds (e.g. 1704067200000000), used in systems requiring extreme precision, such as databases or financial systems.

Year 2038 problem

Traditional Unix in 32-bit systems has a maximum limit of 2,147,483,647 seconds, which corresponds to January 19, 2038. After this date, the value wraps to negative. Modern systems solve this by using 64-bit numbers, which will last for ages. New applications should use milliseconds or nanoseconds to avoid compatibility issues.

Time zones

Unix timestamp is always in UTC, which means it contains no time zone information. To display the date locally, the system adds the time zone offset. For example, the same timestamp value in Poland will be displayed 1 or 2 hours earlier than in the USA (depending on daylight saving time). This makes timestamp ideal for storing and transferring dates between time zones.