How Do Dates Behave in JavaScript?

A date in JavaScript is really just one number. That number is the number of milliseconds since the epoch, and the epoch is midnight on the first of January 1970 in UTC. Everything else you see about a date, such as the year, the month, and the day, is a view over that single number. That is why you can add and subtract dates with plain arithmetic.

The constructor accepts several kinds of value. A string gets parsed, a number is treated as a timestamp, and no argument at all means the current moment. There are also static methods such as Date.now(), which gives the current timestamp, and Date.parse(), which turns a string into a timestamp.

Once you have a date, you read it with getter methods. The local versions, such as getFullYear(), getMonth(), getDate(), and getHours(), use the time zone of the computer. The UTC versions, such as getUTCFullYear(), use UTC instead. And toISOString() always gives a UTC string in one fixed format, which is the one you want when you store a date or send it to an API.

Two details surprise people. Month indexes start at zero, so March is the number two, while the day of the month starts at one, so the first of the month is the number one. There is also an old quirk where a two-digit year between zero and ninety is read as a year in the nineteen hundreds, and that is why setFullYear() always wants the full four-digit year.

The problems with dates come from three sources: time zones, daylight saving changes, and the way the language reads strings.

// A date is a timestamp: the number of milliseconds since the epoch.
const date = new Date('2026-03-01T12:00:00Z');
console.log(date.getTime());          // 1772366400000
console.log(date.toISOString());      // '2026-03-01T12:00:00.000Z'
console.log(date.getUTCDay());        // 0, which is Sunday

// Month indexes start at zero, but day indexes do not.
console.log(date.getMonth());         // 2, which is March
console.log(date.getDate());          // 1

// Add and subtract in milliseconds.
const DAY = 24 * 60 * 60 * 1000;
const later = new Date(date.getTime() + 7 * DAY);
console.log(later.toISOString().slice(0, 10));   // '2026-03-08'

// Work in UTC on the server.
const now = new Date();
console.log(now.toISOString());   // always UTC, whatever the time zone of the machine

The time zone is the biggest problem. A server in one region and a user in another can work out different calendar dates from the same timestamp, unless everybody agrees to use UTC. The fix is to store timestamps, or UTC ISO strings, and to convert to the user's time zone only at the moment you show the date.

Daylight saving changes break the arithmetic. A day is not always exactly twenty-four hours, so adding a fixed number of milliseconds across a change gives you the wrong calendar date. The right way to add a day is to build a new date with a different day number, or to use a date library that handles the changes for you.

Reading strings is the third problem. The specification only requires engines to understand the date and time format, and everything else is up to each engine, so a string like the first of March in a slash format can be read differently in different browsers. Another oddity is that a date on its own is treated as UTC, while a date with a time but no zone is treated as local time. The safe rule is to always pass an explicit offset and to always use the ISO format.

For anything beyond simple timestamps, a date library is the right answer. It gives you time zone handling, local formatting, relative time, and duration arithmetic without the sharp edges.