+ {guide.title} +
+ ++ {guide.cardDescription} +
+ +
+ Converting a Unix timestamp to a date means reading a count of seconds (or
+ milliseconds) since 1970-01-01T00:00:00Z as a calendar moment:{" "}
+ 1700000000 is
+ 2023-11-14 22:13:20 UTC. Converting the other way counts from the epoch again:{" "}
+
+ {`Math.floor(Date.parse("2023-11-14T22:13:20Z") / 1000)`}
+ {" "}
+ returns 1700000000. The{" "}
+
+ Unix Timestamp Converter
+ {" "}
+ does both directions in your browser, with automatic unit detection and no
+ server round trip.
+
+ What a Unix timestamp is +
++ A Unix timestamp (also called epoch time) counts whole seconds from + 1970-01-01 00:00:00 UTC, a fixed reference point + known as the epoch. The value has no timezone attached: + it is one absolute instant, so the same number means the same moment in + every timezone. Instants before the epoch are negative, and instants after + it are positive and grow by one each second. +
+| Timestamp | +Date and time (UTC) | +
|---|---|
| -315619200 | +1960-01-01 00:00:00 (before the epoch) | +
| 0 | +1970-01-01 00:00:00 (the epoch) | +
| 946684800 | +2000-01-01 00:00:00 | +
| 1700000000 | +2023-11-14 22:13:20 | +
| 1792713600 | +2026-10-23 00:00:00 | +
+ Seconds or milliseconds: reading the digits +
++ The same instant can be stored with different precision, and the unit + changes the number of digits. For current dates you can tell them apart by + length alone: +
+| Unit | +Digits in 2026 | +Same instant | +Detected below | +
|---|---|---|---|
| seconds | +10 | +1792713600 | +10^11 | +
| milliseconds | +13 | +1792713600000 | +10^14 | +
| microseconds | +16 | +1792713600000000 | +10^17 | +
| nanoseconds | +19 | +1792713600000000000 | +10^17 or more | +
+ The Timestamp Converter uses exactly these magnitude thresholds and tells
+ you which unit it picked, so a wrong guess is visible instead of silent.
+ One caveat: millisecond values from 1970 to early March 1973 are small
+ enough to fall under the seconds threshold (10^11 ms is 1973-03-03),, so for very old dates choose
+ the unit explicitly rather than relying on auto-detection. JavaScript's{" "}
+ Date.now() always
+ returns milliseconds, which is the unit most JavaScript and Node.js code
+ produces.
+
+ UTC and local time are two views of one instant +
++ Because the number itself carries no timezone, displaying it as UTC or as + your local time changes only the label, never the instant. UTC is the fixed + reference every timestamp is counted against; local time is UTC shifted by + your machine's offset. The converter shows both side by side, plus the + ISO 8601 form, so you can see what a value means locally without losing the + absolute value you should store. +
++ Storage rule of thumb: keep the raw timestamp (or ISO 8601 with a Z or + offset) as the source of truth, and only convert to a local timezone for + display. Two servers in different regions, or one server and a user's + laptop, will otherwise disagree about the same event. +
++ ISO 8601: the readable form of the same instant +
+
+ ISO 8601 writes the instant as calendar fields, for example{" "}
+ 2023-11-14T22:13:20Z{" "}
+ where Z means UTC. An
+ explicit offset such as{" "}
+ 2023-11-15T03:43:20+05:30{" "}
+ describes the same instant from a different timezone. Fractional seconds
+ (22:13:20.000Z) are
+ allowed and are what JavaScript's{" "}
+ toISOString() produces.
+
+ Timestamps and ISO 8601 are two encodings of one value: convert either way + with no information lost, as long as a timezone is present. The converter + normalizes whatever you enter and returns the ISO 8601 string alongside + epoch seconds and milliseconds. +
+
+ Dates before the epoch convert to negative seconds: 1960-01-01 is{" "}
+ -315619200. JavaScript
+ Date and the Timestamp
+ Converter handle these directly, but older C libraries and some SQL
+ columns treat them as errors, so check before passing a negative value to
+ an older system.
+
+ The year 2038 problem is a different limit: systems that store time as a
+ 32-bit signed count of seconds reach{" "}
+ 2147483647 at
+ 2038-01-19 03:14:07 UTC and overflow to a negative number right after.
+ JavaScript stores milliseconds in a 64-bit floating-point number and the
+ converter accepts values within 100,000,000 days of the epoch (about
+ 273,800 years either side), so 2038 is not a limit here. Code compiled for
+ 32-bit platforms with a 32-bit time_t,
+ and any database column typed as a 32-bit integer epoch, still carry the
+ risk and should be migrated before that date.
+
+ Convert in JavaScript and Python +
++ JavaScript works in milliseconds, so multiply seconds by 1000 going one + way and divide going the other: +
+
+ {`// Epoch seconds → date
+new Date(1700000000 * 1000).toISOString(); // "2023-11-14T22:13:20.000Z"
+
+// Epoch milliseconds → the same instant
+new Date(1700000000000).toISOString(); // "2023-11-14T22:13:20.000Z"
+
+// Date → epoch seconds
+Math.floor(Date.parse("2023-11-14T22:13:20Z") / 1000); // 1700000000
+
+// Right now
+Math.floor(Date.now() / 1000); // seconds
+Date.now(); // milliseconds`}
+
+
+ Python's datetime{" "}
+ always needs a timezone for a correct conversion. Pass{" "}
+ timezone.utc in both
+ directions, and remember that a JavaScript milliseconds value must be
+ divided by 1000 first:
+
+ {`from datetime import datetime, timezone
+
+# Epoch seconds → date
+datetime.fromtimestamp(1700000000, tz=timezone.utc)
+# datetime.datetime(2023, 11, 14, 22, 13, 20, tzinfo=datetime.timezone.utc)
+
+# Milliseconds from JavaScript → date
+datetime.fromtimestamp(1700000000000 / 1000, tz=timezone.utc)
+
+# Date → epoch seconds
+int(datetime(2023, 11, 14, 22, 13, 20, tzinfo=timezone.utc).timestamp())
+# 1700000000`}
+
+ + Convert a timestamp step by step +
++ {step.name} +
++ {step.text} +
++ Convert a timestamp in your browser +
++ The{" "} + + Unix Timestamp Converter + {" "} + shows live epoch seconds, milliseconds, and ISO 8601 time, converts a pasted + timestamp to UTC, local time, ISO 8601, and relative time, and converts a + date back to seconds and milliseconds. Unit detection reports what it picked, + and nothing is uploaded, which makes it a safer place to paste an internal + timestamp than a service that posts it to a backend. +
+