Date function itself was no exception. It is based off code that was ultimately deprecated in Java.
Date constructor, so you can avoid them.
let date = new Date(2011, 1, 22); // Notice the date produced has a time attached: // Tue Feb 22 2011 00:00:00 GMT+0000 (Greenwich Mean Time)
Parsing dates as we did above works fine if you know months start at
0, but parsing date strings vary significantly across browsers. It is strongly advised to not parse date strings. Before the ECMAScript 5 specification, how
Date parsed string dates was never defined, and different browsers have many historical quirks that make it very unreliable.
let parseMyDate = Date.parse('2022-03-21T11:00:01+00:00');
However, that is not the case. Many browsers allow date parsing outside of this format. This is where it has the potential to get confusing. Let's say you want to parse a date format in standard
dd/mm/yyyy date format. You take a standard date, and pass it into the
let myDate = new Date("5/1/2020"); console.log(myDate);
In all modern browsers, this uses the US date format, i.e. mm/dd/yyyy - meaning it returns May 1st, not Jan 5th, leading to unexpected results.
Parsing Dates Defaults to UTC
Suppose you have a date which has no time or timezone associated with it:
let myDate = Date.parse('01 Jan 1999'); console.log(myDate);
You might think there is nothing immediately confusing about this - it represents a fixed date in time. However:
- If your timezone is UTC, this will return
- If your timezone is UTC+3:00, this will return
915138000000, i.e. 3 hours more.
- If your timezone is UTC-5:00, this will return
915166800000, i.e. 5 hours less.
So if your timezone is west of UTC, for example,
let date = new Date(2011, 2, 22);
Only, that gives us
let date = new Date(2011, 1, 22);
Incorrect Dates Skip to Next Month
Let's say you have accidentally create an incorrect date, say 31st Feb, 2022. You pass this into your date function, by mistake, from a database or API:
let date = new Date(2022, 1, 31);
You might think that this will just return
Invalid Date or
Date to return errors on all incorrect dates.
Strings are not Parsed to Numbers
parse. For example:
let myDate = new Date("0"); console.log(myDate);
You might think that this will return the year 0, or perhaps the unix epoch, but it actually returns the year
Sat Jan 01 2000 00:00:00 GMT+0000 (Greenwich Mean Time).
Even more strangely, though, if we try to increase this, it starts counting in months:
console.log(new Date("5")); // Tue May 01 2001 00:00:00 GMT+0100 (British Summer Time) console.log(new Date("11")); // Thu Nov 01 2001 00:00:00 GMT+0000 (Greenwich Mean Time) console.log(new Date("4")); // Sun Apr 01 2001 00:00:00 GMT+0100 (British Summer Time)
To top it off, if you try to do
new Date("13"), we'll get
Invalid Date as the result, since there is no 13th month.
Using Timestamps can become confused for dates
If we only pass one number to
new Date(), it will treat it as the Unix timestamp - however, it is not adjusted for timezone. For example, in UTC, the following code returns
Thu Jan 01 1970 00:00:00 GMT+0000 (Greenwich Mean Time):
That makes sense, since it's the Unix epoch, and is probably fine if the specific time is important to you. However, if we are in UTC-5:00, that code returns a different day,
Date().toLocaleString(). Ultimately, we can resolve this by using the method
.toUTCString() - but this complication is not completely obvious.
Years are Inconsistent
You might have thought we've gotten off easy, and only timestamps and timezones are broken - but even years are inconsistent. If we wanted to create a date for the 1st Jan, in the year 0, you might think we'd write this:
console.log(new Date(0, 0, 0));
Since months start from 0, this looks right - but actually, if the year is less than 100, 0 means the year 1900. Alright, you might think, I suppose this should return 1st Jan 1900 instead - but that's actually wrong too - since days are indexed from 1, not 0. The above code returns
Sun Dec 31 1899 00:00:00 GMT+0000 (Greenwich Mean Time) - since the 0th day of the month is counted as the last day from the previous month. Here are a few other examples:
console.log(new Date(0, 0, 0)); // Sun Dec 31 1899 00:00:00 GMT+0000 (Greenwich Mean Time) console.log(new Date(50, 0, 0)); // Sat Dec 31 1949 00:00:00 GMT+0000 (Greenwich Mean Time) console.log(new Date(30, 0, 0)); // Tue Dec 31 1929 00:00:00 GMT+0000 (Greenwich Mean Time) console.log(new Date(24, 0, 0)); // Mon Dec 31 1923 00:00:00 GMT+0000 (Greenwich Mean Time)
As soon as you get above the year 100, it then does go back to counting the years normally. So the below code actually gives us the year 101, not the year 2001:
console.log(new Date(101, 0, 0)); // Fri Dec 31 0100 00:00:00 GMT-0001 (Greenwich Mean Time)
This may be useful if you are using years after 1900, but it is incredibly counterintuitive for anything before.
Date function is fundamentally broken in many ways - which is why most people use tools like Moment.js, but why hasn't it been fixed?
The main reason why they haven't been fixed, is because most of the web has been built on code that took into consideration the flaws with
Date. As such, changing now would result in many websites simply breaking.
Temporal which will occupy a different namespace than
Dates produce. If you're interested in learning more, here are some useful links:
- Learn more about date functions.
- Temporal Specification.
- How to use Environmental Variables in NodeJS
- Web Components and the Shadow DOM
- Setting the Default Node.JS version with nvm