Home → Unix Timestamp in JavaScript
Unix Timestamp in JavaScript
JavaScript uses milliseconds in the built-in Date representation. That difference is one of the easiest timestamp traps when a frontend talks to an API that expects Unix seconds.
Working example
Date.now() returns milliseconds since the Unix Epoch. To obtain Unix seconds, divide by 1,000 and decide how you want to handle the fractional part. To create a Date from Unix seconds, multiply by 1,000 before passing the number to the Date constructor.
Unit and timezone checks
In JavaScript, the crucial context is that Date uses milliseconds while many Unix APIs use seconds. Treat the unit conversion as an explicit boundary between the external value and the Date object.
- Confirm whether the API expects seconds or milliseconds.
- When a calendar value is turned into a timestamp, keep timezone behavior explicit and avoid assuming that a local-looking string is automatically UTC.
- Keep UTC as the reference when comparing distributed logs.
- Do not infer the unit solely from digit count.
Common mistakes in JavaScript
- Passing milliseconds where an API expects seconds.
- Formatting a local time as if it were UTC.
- Dropping fractional seconds when the application requires millisecond precision.
- Using manual UTC offsets instead of the runtime's timezone-aware facilities.
When to use Unix timestamps
JavaScript timestamps appear in browser events, web APIs, frontend state, and logs, so a single seconds/milliseconds mistake can propagate through many layers quickly.
Related Timestamp Tools
Unix Timestamps in JavaScript: Remember Date Uses Milliseconds
JavaScript's built-in Date object represents time internally as a numeric millisecond value relative to the Unix Epoch. This is one of the most common sources of seconds-versus-milliseconds mistakes when JavaScript interacts with APIs that use Unix seconds.
The conversion is explicit
Date.now() returns milliseconds. If an API gives you Unix seconds, multiply by 1,000 before creating a Date: new Date(seconds * 1000). For the reverse direction, Math.floor(date.getTime() / 1000) produces whole Unix seconds, while date.getTime() preserves milliseconds.
Example code
Quick reference
Practical checks
- Treat Date.now() as milliseconds.
- Multiply API seconds by 1,000 before passing them to new Date().
- Use toISOString() for an unambiguous UTC string.
- Do not assume a numeric timestamp is milliseconds just because the application uses JavaScript.
Frequently Asked Questions: Practical Details
Why does new Date(1704067200) look wrong?
The Date constructor interprets the number as milliseconds, while 1704067200 is commonly used as Unix seconds.
How do I get Unix seconds in JavaScript?
Divide Date.now() or getTime() by 1,000 and decide whether you need truncation.
Does toISOString() use local time?
No. It returns an ISO string in UTC, normally ending in Z.
Frequently Asked Questions
How does JavaScript represent the current Unix time?
Check Date.now() and getTime() as millisecond values, then divide by 1,000 only when the API explicitly calls for Unix seconds.
When should JavaScript convert Date values to Unix seconds?
Keep Date values in their native millisecond form inside the application and convert to seconds only when the external API explicitly defines Unix seconds.
How should browser JavaScript handle timezone display?
For browser applications, compare event instants in UTC and use local time only for the user-facing calendar display.