JavaScript Unix Timestamp: Get, Convert & Format Epoch Time

Get the current Unix timestamp

Date.now() returns milliseconds — a 13-digit number. To get the more common seconds value, divide and round down. Never round up: a value like 1767225600.999 is still within the current second.

// Milliseconds since 1970-01-01 UTC (13 digits)
const ms = Date.now();                 // e.g. 1767225600123

// Seconds since 1970-01-01 UTC (10 digits)
const sec = Math.floor(Date.now() / 1000);

Convert a timestamp to a date

new Date(ms) takes milliseconds, so multiply seconds by 1000. The resulting Date is an instant in time with no timezone of its own — it always holds a UTC-based millisecond count, and toISOString() always prints UTC. Local display is a formatting choice, not a change of value.

const ts = 1767225600;                 // seconds
const d = new Date(ts * 1000);
d.toISOString();                       // "2026-01-01T00:00:00.000Z" (UTC)
d.toString();                          // local timezone, e.g. "Thu Jan 01 2026 05:30:00 GMT+0530"

Convert a date back to a timestamp

Date.parse() accepts ISO 8601 strings and returns milliseconds. Two warnings: an ISO string without a zone ("2026-01-01T00:00:00") is parsed as local time, while one with Z is UTC — mixing the two is a one-hour-everywhere class of bug.

Date.parse("2026-01-01T00:00:00Z");  // UTC — deterministic
Date.parse("2026-01-01T00:00:00");    // LOCAL time — changes with the visitor's machine
new Date("2026-01-01").getTime();     // also local time
Math.floor(Date.parse("2026-01-01T00:00:00Z") / 1000); // 1767225600

Timezones: there is no naive Date

JavaScript has exactly one date type: Date, which is always an absolute instant. There is no "local date without a zone" type like Python's naive datetime or Java's LocalDateTime. The pitfalls are therefore about parsing and display, not storage:

• Parsing: zone-less strings are local time. Always append Z for UTC input.
• Display: toISOString() is UTC; toString() and getters like getHours() are local.
• Any timezone: Intl.DateTimeFormat formats in any IANA zone without changing the value.

const d = new Date(1767225600 * 1000);
new Intl.DateTimeFormat("en-US", { timeZone: "Asia/Kolkata",
  dateStyle: "full", timeStyle: "long" }).format(d);
// "Thursday, January 1, 2026 at 5:30:00 AM GMT+05:30"

Native precision: milliseconds

JavaScript's native unit is milliseconds (Date.now(), Date.parse()). For higher precision, performance.now() gives sub-millisecond timestamps but relative to an arbitrary origin — never the Unix epoch. Node.js exposes nanoseconds through process.hrtime.bigint(), also relative, so epoch conversions in Node still go through milliseconds unless you add process.hrtime.bigint() / 1_000_000n + Date.now().

Common pitfalls

• Seconds vs milliseconds: new Date(1767225600) is Jan 1970, not 2026. Multiply by 1000.
• Rounding: Math.round(Date.now() / 1000) can produce next-second values; use Math.floor.
• Date.parse inconsistencies: non-ISO formats like "01/02/2026" parse differently across engines — stick to ISO 8601.
• Mutating dates: d.setHours() mutates in place; copy with new Date(d) first if you need the original.

Try it live

Paste any of these values into the main epoch converter to see them in every format at once, or open the JavaScript snippet tab on the homepage for the current timestamp.