Working with Unix Timestamps in JavaScript
Everything you need to work with Unix timestamps in JavaScript — getting the current time, creating Dates from timestamps, formatting for any timezone, and avoiding common mistakes — with a copy-paste cheat sheet and links to the deep-dive guides.
JavaScript timestamp cheat sheet
JavaScript works in milliseconds: Date.now() and the Date constructor both use milliseconds since the Unix epoch, while most other systems use seconds — so almost every JavaScript timestamp task comes down to remembering a × 1000 or ÷ 1000. The table below is the quick reference; the sections after it explain each operation, and the deep-dive guides cover timezones and the Temporal API in full.
| Task | Code | Result |
|---|---|---|
| Current time (ms) | Date.now() | 1700000000000 |
| Current time (s) | Math.floor(Date.now() / 1000) | 1700000000 |
| Seconds → Date | new Date(s * 1000) | Date object |
| Milliseconds → Date | new Date(ms) | Date object |
| Date → ms | date.getTime() | 1700000000000 |
| Date → ISO 8601 | date.toISOString() | 2023-11-15T06:13:20.000Z |
| ISO string → ms | Date.parse(str) | 1700000000000 |
Getting the current Unix timestamp
JavaScript provides several equivalent ways to get the current time as a numeric timestamp. All of these return the number of milliseconds since the Unix epoch.
- Date.now() → the fastest and most readable — 1700000000000 (milliseconds)
- Math.floor(Date.now() / 1000) → Unix timestamp in seconds — 1700000000
- +new Date() → same as Date.now(), using the unary plus operator
- new Date().getTime() → explicit method call, same result as Date.now()
Creating a Date object from a Unix timestamp
The Date constructor accepts milliseconds since the epoch. Always multiply a seconds-based timestamp by 1000 before passing it to the constructor.
- new Date(1700000000 * 1000) → from seconds (most common case)
- new Date(1700000000000) → from milliseconds (JavaScript APIs, Java)
- new Date(Date.now()) → current time as a Date object
- new Date(0) → the Unix epoch: January 1, 1970 00:00:00 UTC
Formatting dates — built-in string methods
The Date object has several built-in string conversion methods. Each produces a different format.
- .toISOString() → '2023-11-15T06:13:20.000Z' — ISO 8601, always UTC, machine-readable
- .toUTCString() → 'Wed, 15 Nov 2023 06:13:20 GMT' — RFC 7231, human-readable UTC
- .toString() → local timezone string with full zone name
- .toLocaleString() → locale-aware format in the user's local timezone
Timezone-aware formatting
For timezone-aware formatting, use Intl.DateTimeFormat with an explicit timeZone — it applies DST automatically and needs no library. Timezones are a deep topic on their own; the dedicated JavaScript timezone guide covers formatToParts, detecting the user's zone, and the hard wall-clock-to-UTC direction.
- new Intl.DateTimeFormat('en-US', { timeZone: 'America/New_York', dateStyle: 'full', timeStyle: 'long' }).format(date)
- date.toLocaleString('en-GB', { timeZone: 'Europe/London', hour12: false })
Converting a date string back to a Unix timestamp
To go in the opposite direction — from a date string to a Unix timestamp — use Date.parse() or pass the string to the Date constructor.
- new Date('2023-11-15T06:13:20Z').getTime() / 1000 → Unix seconds from ISO 8601 UTC
- new Date('2023-11-15T01:13:20-05:00').getTime() → Unix milliseconds from ISO with offset
- Date.parse('2023-11-15T06:13:20Z') → same as new Date(...).getTime()
- Always use ISO 8601 format with explicit timezone for predictable parsing
Common pitfalls
These are the most frequent mistakes JavaScript developers make with dates and timestamps:
- new Date(1700000000) — missing × 1000 converts to year ~1970 instead of 2023
- getMonth() returns 0–11 not 1–12 — always add 1 when displaying
- new Date('2024-01-01') is UTC midnight; new Date('2024/01/01') is local midnight
- new Date(2024, 0, 1) = January 1 (month is 0-indexed in the constructor too)
- Adding 86400000ms to get 'tomorrow' can fail at DST boundaries — use setDate(d.getDate() + 1) instead
The Temporal API — modern replacement for Date
TC39's Temporal API reached Stage 4 and ships in modern browsers and Node.js. It fixes Date's core flaws — it is immutable, nanosecond-precise, and timezone-aware — and Temporal.Instant is its Unix-timestamp type. The shipped API converts epochs in milliseconds or nanoseconds (the older fromEpochSeconds was removed), so multiply Unix seconds by 1000. See the full Temporal guide for the complete API.
- Temporal.Now.instant() — the current instant, with nanosecond precision
- Temporal.Instant.fromEpochMilliseconds(Date.now()) — from a JS millisecond timestamp
- Temporal.Instant.fromEpochMilliseconds(1700000000 * 1000) — from Unix seconds (× 1000)
- Temporal.ZonedDateTime — instant + IANA timezone, the type Date should have been
- Shipping in Firefox 139+, Chrome 144+, Node.js 26+; Safari in Technology Preview; polyfill for the rest
Going further
FAQ
- How do I get a Unix timestamp in seconds in JavaScript?
- Use Math.floor(Date.now() / 1000). Date.now() returns milliseconds, so divide by 1000 and floor the result to get whole Unix seconds.
- How do I convert a Unix timestamp to a readable date in JavaScript?
- Multiply seconds by 1000, pass to the Date constructor, then format: new Date(1700000000 * 1000).toISOString() gives "2023-11-14T22:13:20.000Z". For a specific timezone, use Intl.DateTimeFormat with a timeZone option.
- Why does new Date() with a Unix timestamp show 1970?
- The Date constructor expects milliseconds. A 10-digit seconds timestamp must be multiplied by 1000: new Date(seconds * 1000).
- How do I format a JavaScript date for a specific timezone?
- Use Intl.DateTimeFormat with an explicit timeZone option, such as new Intl.DateTimeFormat('en-US', { timeZone: 'America/New_York' }). It applies daylight saving automatically and needs no external library.
- Should I use Date or Temporal?
- For new code where the runtime supports it, prefer Temporal — it is immutable, timezone-aware, and avoids Date's footguns. Date remains fine for simple epoch-millisecond work and is still the most widely supported.