Unix Timestamp in JavaScript

JavaScript works in milliseconds everywhere, which is the single biggest source of confusion when talking to APIs that use seconds. Date.now() returns a 13-digit number.

Need to convert one value rather than write code? Use the interactive converter — it handles every unit and time zone without leaving your browser.

Current Unix timestamp

Date.now();                          // 1710050400000  (milliseconds)
Math.floor(Date.now() / 1000);       // 1710050400     (seconds)

// Never use Math.round here — it can push you into the next second.

Timestamp to date

const ts = 1710050400;                     // seconds from an API
const d = new Date(ts * 1000);             // Date wants milliseconds

d.toISOString();                           // '2024-03-10T06:00:00.000Z'
d.toLocaleString('en-GB', { timeZone: 'Asia/Kolkata' });

// Formatting in a specific zone without mutating anything
new Intl.DateTimeFormat('en-GB', {
  timeZone: 'Asia/Kolkata',
  dateStyle: 'full',
  timeStyle: 'long',
}).format(d);

Date to timestamp

// From an ISO string — always include the offset or Z
Math.floor(new Date('2024-03-10T06:00:00Z').getTime() / 1000);

// From local component values (uses the runtime's own zone)
Math.floor(new Date(2024, 2, 10, 11, 30, 0).getTime() / 1000);

// Explicit UTC components, no zone ambiguity
Math.floor(Date.UTC(2024, 2, 10, 6, 0, 0) / 1000);   // month is 0-indexed

Temporal (the modern API)

// Stage 3 proposal, shipping in browsers and available via a polyfill.
const inst = Temporal.Instant.fromEpochSeconds(1710050400);
inst.toZonedDateTimeISO('Asia/Kolkata').toString();

Temporal.Now.instant().epochMilliseconds;

Pitfalls specific to JavaScript

  • Month is zero-indexed in new Date(y, m, d) and in Date.UTC — March is 2.
  • new Date("2024-03-10") parses as UTC midnight, but new Date("2024-03-10T00:00:00") parses as local midnight. That inconsistency is in the spec.
  • Nanosecond timestamps exceed Number.MAX_SAFE_INTEGER. Parse them with BigInt before dividing down.

Rules that apply in every language

  1. Store UTC, display local. Keep the instant in UTC everywhere in your system and convert only at the point a human reads it.
  2. Name the unit in the identifier. expires_at_ms rather than expires_at costs nothing and prevents the single most common timestamp bug.
  3. Never trust a client clock. Stamp anything security-relevant on the server. See the note on clock skew.
  4. Use 64-bit time. Anything still storing seconds in a signed 32-bit field breaks in January 2038 — see the Year 2038 problem.

The same task in other languages

Frequently asked questions

How do I get the current Unix timestamp in JavaScript?

Use the snippet in the "Current Unix timestamp" section above. JavaScript works in integer milliseconds natively, so converting to another unit is a multiplication or an integer division away.

How do I convert a Unix timestamp to a date in JavaScript?

The "Timestamp to date" snippet above shows the idiomatic approach, including how to render the result in a specific time zone rather than whatever zone the machine happens to be set to.

Does JavaScript handle time zones and daylight saving correctly?

Yes, provided you pass an explicit zone rather than relying on the system default. The gotchas listed on this page cover the specific ways JavaScript makes that easy to get wrong.