Epoch Converter

Current Unix Epoch

A log line says 1729523412, an API returns 1729523412000, a database writes 1729523412.845293. All three are the same instant since January 1, 1970 UTC: the first in seconds, the second in milliseconds, the third in seconds with a fractional part. This converter goes both ways: paste a timestamp to read the UTC date and time, or enter a date to get the epoch value in seconds or milliseconds.

How to convert an epoch timestamp

  1. 1

    Paste a timestamp

    A value in seconds (10 digits), milliseconds (13 digits), or with a fractional part such as 1729523412.845293.

  2. 2

    Pick the precision

    The switch above the input selects seconds or milliseconds. The date result keeps fractional seconds down to microseconds.

  3. 3

    Read the UTC date

    The converted value appears in UTC as YYYY-MM-DD HH:MM:SS.microseconds, ready to copy.

  4. 4

    Reverse it

    Enter a date and time in UTC, and get the epoch value in seconds or milliseconds.

What is “the epoch”

Unix time measures seconds (or fractions thereof) since January 1, 1970 00:00:00 UTC, known as the Unix epoch. It is the dominant machine-readable timestamp in software:

  • POSIX systems: time() returns seconds since epoch.
  • JavaScript: Date.now() returns milliseconds.
  • Java: System.currentTimeMillis() returns milliseconds.
  • Go: time.Now().Unix() returns seconds; UnixNano() returns nanoseconds.

Precision by magnitude

Digit count Precision Example
10 seconds 1,729,523,412
13 milliseconds 1,729,523,412,000
16 microseconds 1,729,523,412,000,000
19 nanoseconds 1,729,523,412,000,000,000

This converter accepts seconds, milliseconds and fractional values; set the precision switch to match your input.

Landmark timestamps

  • 0 - January 1, 1970 00:00:00 UTC. The epoch itself.
  • 1,000,000,000 - September 9, 2001 01:46:40 UTC. A common “billion-second” party moment.
  • 1,234,567,890 - February 13, 2009 23:31:30 UTC.
  • 2,147,483,647 - January 19, 2038 03:14:07 UTC. The Y2K38 problem: signed 32-bit overflow.
  • 10,000,000,000 - Far future: November 20, 2286 17:46:40 UTC.

The Y2K38 problem

Systems storing Unix time in a signed 32-bit integer overflow at 2,147,483,647 seconds (January 19, 2038). Modern systems use 64-bit integers, which push the problem out past the heat death of the Sun. Legacy embedded systems and old databases may still be affected; check your stack.

Timezone subtleties

Epoch time is inherently UTC. When you convert it for display, you apply a timezone:

  • IANA name (America/Los_Angeles, Europe/Berlin): handles daylight saving automatically.
  • Offset (-08:00, +05:30): fixed offset, no DST awareness.
  • Abbreviation (PST, CEST): ambiguous; different regions use the same abbreviations. Avoid for storage.

DST rules change over time. A historical timestamp in America/New_York uses the DST rules that were in effect on that date, not today’s rules. This converter always displays UTC. To see the instant in your own region, interpret the UTC result with an IANA name or a fixed offset.

ISO 8601 vs RFC 2822

For timestamps in data formats:

  • ISO 8601 (2024-10-21T14:30:12Z): preferred modern standard, sortable, unambiguous.
  • RFC 2822 (Mon, 21 Oct 2024 14:30:12 +0000): used in HTTP headers and email.

For display to humans: local format following their locale conventions.

Working with leap seconds

POSIX time does not count leap seconds; it silently jumps backward for one second when a leap second is inserted. TAI (International Atomic Time) does count them. For most application code, POSIX is correct; for astronomy, geodesy and precision timing, use TAI or UTC with leap-second awareness.

Frequently Asked Questions

Check the precision switch: a milliseconds value (13 digits) interpreted as seconds yields a date far in the future. The tool always displays UTC, so compare the result against your local offset before converting.

Yes. The tool accepts negative timestamps, which represent dates before the Unix epoch. December 31, 1969 23:59:59 UTC is -1.

Store epoch (UTC) and an IANA timezone name as separate fields. ISO 8601 with offset (e.g. 2024-10-21T14:30-07:00) carries the offset, but loses the ability to reinterpret under changed DST rules. Use IANA names for canonical storage.

No. The value is sent to the server only to run the conversion, and it is not stored or logged. The tool records an anonymous count of conversions without the value.

Related Tools

Tool available in other languages