Why does `new Date()` give a different time than my system clock?

It does not. `new Date()` reads the same OS clock that your system tray shows. What differs is the format: `Date.toString()` shows your local zone, while your clock might show UTC or a different zone. Check `getTimezoneOffset()` to see the raw offset.

Is `toISOString()` always in UTC?

Yes. `toISOString()` always returns a string in UTC, ending in `Z`. It is the only built-in method that is guaranteed to be zone-free. Use it for storage and network transmission.

What is the difference between `getTime()` and `getTimezoneOffset()`?

`getTime()` returns the milliseconds since the epoch, a number that is the same everywhere. `getTimezoneOffset()` returns the difference in minutes between UTC and local time, a number that shifts with DST and location. Use `getTime()` for logic, `getTimezoneOffset()` only for output.

Should I store dates in UTC in my database?

Yes. Store UTC moments in your database. If you need to know the local time, store the IANA zone separately. The alternative, storing local times, breaks the moment DST rules adjust, which happens multiple times per year as governments update their regulations.

Why does my code break in March and November?

Because those are the months of DST transitions. Spring-forward skips an hour; fall-back repeats one. Any code that assumes every local day has 24 hours, or that local times are unique, will break. Use UTC for all logic and local time only for output.

What is the year 2038 problem?

On 19 Jan 2038 at 03:14:07 UTC, signed 32-bit time values overflow. Any system still using 32-bit seconds since the epoch will fail. JavaScript uses 64-bit floating-point milliseconds, so it is safe, but many embedded systems, legacy databases, and some file formats are not.

JavaScript Date Pitfalls: Time Zones, Parsing, and Bugs

Your JavaScript dates are off by one hour because the Date object stores a single moment as UTC milliseconds, but every display method applies your system's local time zone, and that zone is not always what you think it is.

The Date object represents a single point in time as milliseconds since 1 Jan 1970 UTC. Internally it is UTC milliseconds. Only display methods apply local zone. That sounds simple. It is not. The bugs come from parsing strings, assuming the browser asked the network for the time, and forgetting that daylight saving time makes some local times exist twice, or not at all.

The Date Object: UTC Inside, Local Outside

Every JavaScript Date is just a number: milliseconds elapsed since the Unix epoch. new Date() grabs the current moment from your operating system's clock. Date.now() returns that same number directly.

The confusion starts when you want to show the time. Methods like .toString(), .toLocaleString(), .getHours(), and .getMonth() all convert that UTC moment into your local wall-clock time. The underlying point in time never shifts. What shifts is the zone applied at formatting time.

Here is the trap: your code runs on a server in one zone and a user in another. The server stores new Date(). That is fine. But if you call .getHours() on the server to decide something about the user's day, you get the server's morning, not the user's.

Skip that pattern entirely. Run logic on the UTC timestamp. Apply the zone only when you render output.

Why `new Date('2026-01-01')` Behaves Differently Across Browsers

Parse a date string and you enter a minefield. The ECMAScript specification says that a date-only string like '2026-01-01' is interpreted as UTC. A full ISO string with a time and timezone, like '2026-01-01T12:00:00Z', is also UTC. But a string with no timezone and no Z, like '2026-01-01 12:00:00', is parsed as local time in every modern browser.

That split causes real bugs. new Date('2026-01-01') gives you midnight UTC, which in New York is December 31 at 7 PM. If you then call .getDate(), you get 31, not 1. The date silently shifted.

Older browsers used to parse '2026-01-01' as local time. They were wrong per the spec, but they were consistent with what many developers expected. The spec changed, browsers followed, and code broke.

Never parse date strings with new Date(). If you receive an ISO 8601 string, parse it yourself or use a library. If you control the format, use '2026-01-01T00:00:00' and know that it means local time. Better: always include the Z or an offset.

The DST Transition Trap: Missing and Duplicate Hours

Daylight saving time is not a technical detail. It is a government decision that alters the length of a day. On spring-forward, the clock jumps from 2:00 AM to 3:00 AM. The local time 2:30 AM never occurs. On fall-back, the clock drops from 2:00 AM to 1:00 AM. The local time 1:30 AM occurs twice.

Ambiguous local time occurs twice during the fall-back DST shift. Invalid local time never occurs during the spring-forward shift. JavaScript will happily accept both. new Date(2026, 2, 8, 2, 30) in a zone that springs forward will not throw an error. It will give you a valid moment, just not the one you meant.

What happens is implementation-dependent. Some browsers pick the first occurrence, some pick the second. The spec says either is acceptable. Your code can produce different results depending on the browser, the OS, and the zone database version.

Store moments, not wall-clock times. If you need "2:30 AM on March 8," store the UTC moment and the IANA zone separately. Then format for output. Never do arithmetic on local times across a DST boundary.

When should I use toISOString() to avoid the javascript date timezone problem?

toISOString() converts the moment to a string in UTC. It always ends in Z. It is unambiguous, sortable, and the right choice for storage and transmission.

toString() converts to your local time. It includes the zone abbreviation and offset. It is human-readable but useless for comparison.

toLocaleString() does something in between: it formats for a locale, and if you pass a timeZone option, it can format for any zone. new Date().toLocaleString('en-US', { timeZone: 'America/New_York' }) gives you New York time regardless of where the code runs.

The mistake people make is using toISOString() for output. It is not wrong, it is just UTC. If your user is in Tokyo, showing them 2026-01-01T03:30:00.000Z means nothing. Use toLocaleString() with the user's zone, or let the browser do it by not passing a zone at all.

How does Intl.DateTimeFormat solve the javascript date timezone problem?

Intl.DateTimeFormat is the built-in answer to formatting. It handles locales, zones, and calendars. It does not handle parsing. It does not handle arithmetic. It formats.

The key method is resolvedOptions(). Call Intl.DateTimeFormat().resolvedOptions().timeZone and you get the IANA zone identifier for the current environment, something like America/New_York or Asia/Kolkata. This is how you find out what zone the browser thinks it is in.

Why does this matter? Because the browser gets both the moment from the OS clock and the zone from OS region settings. If a user travels and adjusts their clock but not their region, the moment shifts but the zone does not. If they adjust their region but not the clock, the zone shifts and every local rendering moves.

Use Intl.DateTimeFormat for all user-facing output. Pass the timeZone option explicitly when you know the target zone. Let the user's locale control the format. That is what the API is for.

How can I detect the user's time zone to fix the javascript date timezone problem?

The timeZone property returns an IANA zone identifier. It is not an abbreviation like EST or PST. Those are ambiguous, CST means UTC−6 in North America, UTC+8 in China, and UTC+9:30 in Australia. IST means UTC+5:30 in India, UTC+2 in Israel, and UTC+1 in Ireland.

An IANA identifier like America/Chicago is unambiguous. It encodes the full history of offset adjustments for that region, including every DST rule ever applied. That is what you want for storage and logic.

If you need the current offset, use Date.prototype.getTimezoneOffset(). It returns minutes ahead of UTC, negative for zones east of UTC, positive for west. It is a raw number with no zone information. It tells you nothing about whether DST is in effect or when it shifts.

Common Bugs: Off-by-One-Hour, Wrong Day, and More

The off-by-one-hour bug is the most common. It appears when you store a date, read it back, and the rendered time is one hour off. The cause is almost always a zone mismatch: you stored a local time as if it were UTC, or you stored UTC and formatted it as local.

Another classic: new Date('2026-07-01') gives you July 1 UTC. In Los Angeles, that is June 30 at 5 PM. If you then call .toLocaleDateString(), you get 6/30/2026. The date shifted because the moment is the same but the zone is different.

A third: using getMonth() and getHours() for logic. These return local values. If you use them to build a key, a filename, or a database query, you get different results depending on where the code runs.

The root cause is always the same: treating a Date as if it stored a wall-clock time. It does not. It stores a moment. Every local method is a view of that moment through a zone.

Best Practices for Date Handling in JavaScript

Store moments, not wall-clock times. Use Date.now() or new Date() for the current moment. Store the resulting number or an ISO 8601 string with a timezone. Never store a string without a zone unless you also store the zone separately.

Use toISOString() for storage and transmission. It is unambiguous and sortable.

Use Intl.DateTimeFormat for output. Let the user's locale and zone control the rendering.

Never parse date strings with new Date(). Parse the components yourself, or use a library like date-fns-tz or Luxon. These handle the edge cases the spec leaves open.

Never do arithmetic on local times. Add or subtract milliseconds from the moment, then format. new Date(date.getTime() + 24 * 60 * 60 * 1000) adds a day. date.setDate(date.getDate() + 1) does not, it can produce 23 or 25 hours on DST days.

For future events, store the wall-clock time, the IANA zone, and the moment. The moment might shift if the government adjusts the rules. The wall-clock time and zone are what you show.

Common JavaScript Date Pitfalls and How to Avoid Them