How to Convert Timestamps in JavaScript: Unix, ISO 8601, and More

#webdev #tools #javascript #programming

Timestamp handling is one of those things every JavaScript developer does constantly but rarely thinks about systematically — until a bug caused by a missing * 1000 or an unexpected timezone shift hits production. This guide is a complete reference for how to convert timestamps in JavaScript: Unix seconds to ISO 8601, the Date object API, timezone formatting with Intl.DateTimeFormat, and when to reach for a library like date-fns or dayjs.

For quick conversions between Unix timestamps and human-readable dates, use our Timestamp Converter — no code required.

The JavaScript Date Object

The built-in Date object is JavaScript's foundation for time. All timestamps internally are stored as milliseconds since the Unix epoch (January 1, 1970, 00:00:00 UTC):

{codeDateBasics}

The most common gotcha: the Date constructor's month parameter is 0-indexed (January = 0, December = 11). This is a legacy quirk you cannot avoid — just memorize it.

Unix Timestamps: Seconds vs. Milliseconds

Unix timestamps traditionally count seconds since the epoch. JavaScript's Date object works in milliseconds. This mismatch is the source of countless bugs:

{codeUnixConvert}

Quick way to tell them apart: a Unix timestamp in seconds is ~10 digits (1711000000). In milliseconds it's ~13 digits (1711000000000). If you get a timestamp from a language like Python, Go, or a database, it's almost certainly in seconds — multiply by 1000 before passing to new Date().

ISO 8601: The Right Format for Storing and Transmitting Dates

When storing dates in databases, sending them in API responses, or serializing them to JSON, always use ISO 8601. It's unambiguous, sortable as a string, and universally parseable:

{codeISO8601}

The critical rule: always include the timezone designator (Z for UTC, or +HH:MM offset) when storing datetimes. An ISO string without a timezone is ambiguous — different environments will interpret it as local time, which changes value depending on where the code runs.

Timezone Handling

Timezone bugs are among the hardest to reproduce because they depend on the machine's local settings. The safest approach: store all times in UTC, convert to local time only at display time.

{codeTimezone}

The Intl.DateTimeFormat API is built into all modern browsers and Node.js 12+. It uses the IANA timezone database (e.g., America/New_York), which handles daylight saving time automatically. Avoid using numeric UTC offsets (+05:30) for timezone IDs — they don't account for DST.

When you need to inspect a specific Unix timestamp in a different timezone, our Timestamp Converter handles all the conversions with a visual interface.

date-fns: The Functional Approach

For projects that need more than the native Date API offers, date-fns is the most popular modern choice. It's fully tree-shakeable — you only bundle the functions you actually import:

{codeDateFns}

date-fns treats all Date objects as immutable (no mutation), and its functions are pure — given the same inputs, you always get the same output. This makes it predictable in React components and easy to test. The timezone support is in a separate date-fns-tz package.

dayjs: The Lightweight Moment Replacement

If you're migrating from Moment.js (which is now in maintenance mode), dayjs has a nearly identical API but weighs only ~2KB. Plugins extend it with UTC, timezone, and relative time support:

{codeDayjs}

Choose dayjs when you want a familiar chained API and need to keep bundle size minimal. Choose date-fns when you want pure functions, TypeScript-first design, and fine-grained tree-shaking.

Common Conversion Cheat Sheet

{codeCommonConversions}

Want these tools available offline? The DevToolkit Bundle ($9 on Gumroad) packages 40+ developer tools into a single downloadable kit — no internet required.

Summary

JavaScript's Date uses milliseconds; APIs and databases often use Unix seconds — always check which you have.
Use Date.now() for current Unix milliseconds; divide by 1000 for seconds.
Always include a timezone designator (Z or offset) in ISO 8601 strings.
Use Intl.DateTimeFormat with IANA timezone IDs for DST-aware display formatting.
Use date-fns for functional/immutable patterns; use dayjs for a lightweight Moment-like API.