Unix epoch converter

How to use

1. Paste the number into Unix timestamp. Digits, an optional minus sign and one decimal point are accepted; underscores are ignored. Hexadecimal and scientific notation such as 1.7e9 are refused rather than rounded, because a rounded timestamp is a wrong timestamp.
2. Leave Unit on Auto, or choose the unit you know. With Auto the rule is: a whole-number part below 1e11 is seconds, below 1e14 milliseconds, below 1e17 microseconds, and above that nanoseconds. The status line says which was chosen, and the table "How each unit would read these same digits" shows all four readings.
3. Choose the zone for the local time. The filter box narrows the list of zone names the browser knows. The UTC result does not depend on this choice.
4. Read the result: the big line is UTC in ISO 8601 / RFC 3339 form. Below it are the local time with its offset, the RFC 5322 and HTTP-date spellings, the weekday, day of year and ISO week, and the same instant in all four units as exact integers.
5. To go the other way, type a date and time in Date to epoch number (YYYY-MM-DD hh:mm:ss, with an optional fraction) and say whether those clock fields are UTC or in the zone chosen above. If the zone has a clock change at that moment, the page tells you the reading never happens or happens twice and shows what it did.

All arithmetic uses exact integers (BigInt), so a nanosecond timestamp keeps all of its digits. A JavaScript Number cannot: it holds integers exactly only up to 2⁵³ - 1, about 9.0e15, and a nanosecond timestamp for 1 October 2026 (1790812800000000000, which is 2026-10-01T00:00:00Z) is about 1.79e18, nearly 200 times too big for that.

Worked examples

Every result printed here is recomputed by an automated test from the same engine as the tool, and the key ones are also checked against JavaScript's own Date in the tests.

One instant in four units

1700000000 seconds after 1970-01-01T00:00:00Z is 22:13:20 UTC on 14 November 2023. The same instant is 1700000000000 milliseconds, and it keeps whatever finer digits you give it.

The edges: zero, minus one, the largest 32-bit value

2147483647 is 2³¹ - 1, the largest signed 32-bit integer; the year 2038 page shows what happens one second later.

Local time in other zones

Jakarta is UTC+7 all year, so 22:13:20 UTC is 05:13:20 the next morning. Kathmandu is UTC+5:45, so the minutes change too.

Either side of a clock change

New York sprang forward at 07:00:00 UTC on 8 March 2026. One second before that instant local time was 01:59:59 at -05:00; at that instant it is 03:00:00 at -04:00. The hour from 02:00 to 02:59 never appears on a New York clock.

Date to number

The same clock reading is 18000 seconds (5 hours) later in New York, because New York was at UTC-5 on that date. One second before the epoch, and the last second of year 9999:

The same task in code

These are the shortest correct versions in each language. The ones marked as executed were run while this page was written and print exactly what is shown; the others were not run (see the notes under each).

Epoch seconds to a UTC date-time (1700000000)

console.log(new Date(1700000000 * 1000).toISOString());

from datetime import datetime, timezone
print(datetime.fromtimestamp(1700000000, tz=timezone.utc).isoformat())

fmt.Println(time.Unix(1700000000, 0).UTC().Format(time.RFC3339))

SELECT datetime(1700000000, 'unixepoch');

System.out.println(java.time.Instant.ofEpochSecond(1700000000L));

SELECT to_timestamp(1700000000) AT TIME ZONE 'UTC';

SELECT FROM_UNIXTIME(1700000000);

A UTC date-time to epoch seconds (2023-11-14 22:13:20)

console.log(Date.UTC(2023, 10, 14, 22, 13, 20) / 1000);

from datetime import datetime, timezone
print(int(datetime(2023, 11, 14, 22, 13, 20, tzinfo=timezone.utc).timestamp()))

fmt.Println(time.Date(2023, 11, 14, 22, 13, 20, 0, time.UTC).Unix())

SELECT unixepoch('2023-11-14 22:13:20');

SELECT UNIX_TIMESTAMP('2023-11-14 22:13:20');

System.out.println(java.time.LocalDateTime.of(2023, 11, 14, 22, 13, 20).toEpochSecond(java.time.ZoneOffset.UTC));

What goes wrong

Real inputs that surprise people. Each result is the tool's exact output and is covered by a test.

The unit guess can be wrong

A count of 253402300800 is 1 January 10000 if it is seconds. Auto-detect sees 12 digits, which is above its 1e11 limit for seconds, and reads milliseconds instead.

Numbers around 8 or 9 digits are plausible dates in more than one unit. 86400000 is 1000 days in seconds and exactly one day in milliseconds:

A consequence of the thresholds: a millisecond timestamp for a date before 1973-03-03 has fewer than 12 digits and is read as seconds, and a seconds timestamp after 5138-11-16 has 12 digits and is read as milliseconds.

The wrong unit by a factor of 1000

If a date lands in 1970 or in the year 50000, a factor of 1000 is the first thing to check.

Refused inputs

Big numbers and the end of the range

The largest signed 64-bit integer, read as nanoseconds, is in April 2262. Go's documentation says Time.UnixNano is undefined for dates before the year 1678 or after 2262 for exactly this reason; this page keeps all nine digits and has no such limit.

A clock reading that is not one instant

"Date to epoch" with a zone needs the clock reading to name exactly one instant. On 8 March 2026 New York skips from 01:59:59 to 03:00:00, and on 1 November 2026 the hour from 01:00 to 01:59 happens twice. The page says so instead of picking silently.

The time zone converter lets you choose what to do in each case.

The month number in code

In JavaScript's Date.UTC(2023, 10, 14, ...) the month is 0-based, so 10 means November (see the snippet above). Passing 11 for November gives December, a month off and no error.

Limits & gotchas

• Leap seconds are not counted. POSIX defines seconds since the Epoch with every day exactly 86400 seconds, so the number does not advance during a leap second. JavaScript and SQLite document the same. A time of day such as 23:59:60 therefore has no timestamp of its own; the ISO 8601 validator shows how it is mapped.
• The unit guess is a rule of this site. It is not a standard. It separates the units only by magnitude, so it cannot tell 1000 days in seconds from one day in milliseconds, and it reads dates before 1973-03-03 written in milliseconds as seconds.
• Before 1970 and far from it. POSIX leaves the relationship undefined for negative values. The tool follows JavaScript: the proleptic Gregorian calendar extended backwards and forwards, with years outside 0000-9999 written in the signed, six-digit expanded form (+010000). Its limit is 100,000,000 days either side of 1970 (about the years -271821 to +275760).
• RFC 5322 and HTTP-date have limits of their own. RFC 5322 needs a year of at least 1900 and 4 digits, and the HTTP-date form is always in GMT with a 4-digit year. Where a date cannot be written in that form, the page says "not available" instead of inventing a spelling.
• Local time depends on your browser's time zone data. It comes from the browser's copy of the IANA database, which can lag behind rule changes (see the FAQ). While testing this site we saw it directly: a Node release carrying 2024b data and the 2026c data on the build machine disagreed about Africa/Casablanca after 2026-09-20. The UTC column is not affected.
• Weekday, day of year and ISO week refer to the UTC date. The local date can differ near midnight.

FAQ

Sources

• The Open Group: POSIX.1-2024 Base Definitions, 4.19 Seconds Since the Epoch Used for: Seconds since the Epoch "approximates" the seconds elapsed since the Epoch; the formula that relates a UTC date to it for years from 1970 and non-negative values; "If the year is <1970 or the value is negative, the relationship is undefined"; "each and every day shall be accounted for by exactly 86400 seconds" (so leap seconds are not counted); the relationship to actual UTC is unspecified.
• Ecma International / TC39: ECMAScript Language Specification: Time Values and Time Range; Date.parse; time zone offset helper operations Used for: A time value is milliseconds since 1970-01-01T00:00:00Z with every day exactly 86,400,000 ms (leap seconds are ignored); the range is +-8.64e15 ms (+-100,000,000 days); for a local time that is skipped or repeated, the offset in use before the transition is applied; a skipped local time yields no instant in the time-zone-to-epoch operation.
• MDN Web Docs: Date Used for: The supported range (April 20, 271821 BC to September 13, 275760 AD, plus or minus 100,000,000 days); that Date ignores leap seconds; Number.MAX_SAFE_INTEGER is 9,007,199,254,740,991; the date-time string format (a simplification of ISO 8601, 24:00:00 allowed, expanded years of + or - followed by six digits, -000000 disallowed); and that setting a local time inside a DST transition follows the Temporal "compatible" disambiguation: if the local time corresponds to two instants the earlier one is chosen, and if it does not exist the result goes forward by the gap duration (with the New York 2024 example).
• SQLite: Date And Time Functions Used for: The unixepoch and auto modifiers; with auto, a number between 0.0 and 5373484.499999 is read as a Julian day number and, outside that, a number from -210866760000 to 253402300799 is read as a Unix timestamp; SQLite computes as if every day is exactly 86400 seconds, with no leap seconds.
• IANA: leap-seconds.list Used for: The 27 leap seconds inserted since 1972 (TAI minus UTC rose from 10 s to 37 s, last step at the end of 2016-12-31) and that the file carries an expiry time (2027-06-28), after which it must be re-read.
• IANA: News for the tz database Used for: Recent rule changes made on short notice: release 2026c (2026-07-08) lists Alberta moving to permanent -06 and Morocco to permanent +00 from 2026-09-20; release 2026e (2026-09-29) lists Manitoba moving to permanent -05 on 2026-10-31.
• IETF (RFC Editor): RFC 5322: Internet Message Format, section 3.3 Date and Time Specification Used for: The date-time layout "Thu, 01 Oct 2026 00:00:00 +0000" with an optional day of week, and that a year is at least four digits and must be 1900 or later.
• IETF (RFC Editor): RFC 9110: HTTP Semantics, section 5.6.7 Date/Time Formats Used for: The preferred HTTP-date form, IMF-fixdate ("Sun, 06 Nov 1994 08:49:37 GMT"), which is always in GMT.
• The Go Authors: Go package time: Date Used for: Time.UnixNano is undefined for dates before the year 1678 or after 2262 (it must fit an int64). time.Date: in a transition that skips or repeats times (the doc's example is the US, 2011), "Date returns a time that is correct in one of the two zones involved in the transition, but it does not guarantee which."
• Oracle: MySQL 8.4 Reference Manual: Date and Time Functions Used for: FROM_UNIXTIME() returns values in the current session time zone, and UNIX_TIMESTAMP() assumes that its argument is a datetime value in the session time zone.
• MDN Web Docs: Intl.supportedValuesOf() Used for: "timeZone" is a valid key and the call returns a sorted array of unique values supported by the implementation.

Every document above was opened and read on 2026-10-03. Documentation changes; if a page here disagrees with the current docs, trust the docs and tell us.

Related tools

• Time zone converter

  Convert a local time between IANA zones and see what happens when the time does not exist or happens twice.

• ISO 8601 and RFC 3339 validator

  Check a date-time against both formats and see exactly why a string is or is not valid.

• Year 2038 problem demo

  Watch a signed 32-bit seconds counter overflow, with the exact instants and what each reading means.

• Date difference and add/subtract

  Calendar and elapsed-time arithmetic that is honest about DST, with month-end clamping explained.