Convert a Unix timestamp to time in JavaScript
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
Unix timestamps represent a point in time as a number counted from the Unix epoch, which begins at midnight UTC on January 1, 1970. Converting them in JavaScript is easy once you remember one critical rule: Date expects milliseconds, while many Unix timestamps are expressed in seconds.
Seconds Versus Milliseconds
This is where most bugs come from. An API may return 1719830400, which means seconds since epoch. JavaScript's Date constructor expects 1719830400000 if you want the same instant.
If you forget to multiply by 1000, the result points to a date near January 1970 instead of the modern time you expected.
Converting Milliseconds Directly
Some systems already send epoch milliseconds. In that case, do not multiply again.
The constructor stores the timestamp internally as milliseconds from the epoch.
Formatting the Time for Humans
Once you have a Date, you can format it several ways depending on the audience.
These methods answer different questions:
- '
toISOString()gives a stable UTC representation.' - '
toUTCString()is readable but still UTC-based.' - '
toLocaleString()formats for a locale and optional timezone.'
Extracting Just the Time Portion
If you only need the time, read the components explicitly.
Using the UTC getters keeps the result independent of the machine's local timezone. If you want local time, use getHours, getMinutes, and getSeconds instead.
Reusable Helper Functions
It is worth centralizing conversion logic so the rest of the codebase does not guess about units.
One helper is enough to eliminate repeated unit mistakes across an application.
Going the Other Direction
JavaScript can also convert a Date back into Unix time.
getTime() always returns milliseconds. If another system expects seconds, divide and choose the rounding behavior deliberately.
Timezones Do Not Change the Instant
A Unix timestamp is timezone-agnostic. The timezone only matters when you display or interpret the instant for humans. Two systems in different timezones can show different clock times for the same timestamp while still referring to the exact same moment.
That is why toISOString() is often the safest format for logs, APIs, and debugging.
Common Pitfalls
The biggest pitfall is confusing seconds and milliseconds. That single mistake produces dates that are wildly wrong while still looking syntactically valid.
Another issue is assuming Date stores local time. Internally it stores an instant. Local or UTC behavior comes from the formatting and getter methods you choose.
Developers also forget to validate numeric input. If a timestamp comes from user input or an external API, protect the conversion path with simple checks before creating the Date.
Finally, avoid manual string slicing on raw timestamps when what you really need is date formatting. Convert to a Date first, then format intentionally.
Summary
- JavaScript
Dateexpects milliseconds since the Unix epoch. - Multiply Unix seconds by
1000before creating aDate. - Use
toISOString()for stable UTC output and locale-based methods for user-facing output. - Choose UTC getters or local getters based on the display requirement.
- Put timestamp conversion in helper functions so unit handling stays consistent.

