The Date API has certainly been used by everyone, although the handling of dates is mostly left to DayJS or moment.

But we’re going to have to go straight to the native API, and you’re going to have to say, “What hell?” Let’s take a look at what’s wrong with this API.

Date supports the following types of parameters:

new Date(a);new Date(value);
new Date(dateString);
new Date(year, monthIndex [, day [, hours [, minutes [, seconds [, milliseconds]]]]]);
Copy the code

Once you know the parameter types, you can use them directly:

Nothing wrong, as expected, no parameter to get the current system time.

So what if we write it another way, pass in a string?

My little head is full of question marks. I pass in the same date, but the format is changed, why the output content is completely different?

As I’ll explain, when we enter the first format, it internally parses it to coordinated Universal Time (UTC) for the current time zone, which is zero plus eight hours.

When we enter the second format, it is internally resolved to zero for the current time zone.

Here in fact, the author has a little meng forced, do not step on this pit ghost know there will be such a difference.

You think this is the end of it? Naive, let’s look at this again:

Good guy, I this pass obviously is July, how to give me the resolution into August??

This may seem like a Bug, but it’s actually an old tradition that goes back a long time and does start with 0 as the starting bit for certain times in programming languages:

You can read about this in the Linux documentation.

This is not the end of the article, let’s change the way to look at:

I can understand a little bit about this first notation, since the year 1900 is the year of counting, but why did you write the year 2032 instead of an array?

The author here also did not archaeology, anyway kill do not write so on the line.

Update: Because [32, 10, 4] is converted to a string, that is, new Date(’32, 10, 4′), the result looks like this.

So many pits, heart tired, use new Date() in the future, but actually sorry, you may also step on a pit with this alone.

For example, we always set an expires field on the server to the interface setCookie to indicate how long the Cookie will last. If your expires field is generated as a new Date(), be sure to convert it.

For example, we use new Date() to obtain a time, you can see the output with Chinese:

TypeError: invalid character in header content [“set-cookie”] TypeError: invalid character in header content [“set-cookie”] TypeError: invalid character in header content [“set-cookie”] TypeError: Invalid character in header content [“set-cookie”]

So we need to do a conversion of this time to get a time string without Chinese.

Having said all that, is the native API really dead? Do you have to use all the libraries? This is not true. TS39 also knows that such a sheol API is not easy to use, so it made the proposal-temporal proposal to solve the problem, which is the integration of the function of the current date processing library.

However, when this proposal is compatible with most browsers, I don’t know, I’ll stick with DayJS.