Why Does Date.Parse Give Incorrect Results

Why does Date.parse give incorrect results?

Until the 5th edition spec came out, the Date.parse method was completely implementation dependent (new Date(string) is equivalent to Date.parse(string) except the latter returns a number rather than a Date). In the 5th edition spec the requirement was added to support a simplified (and slightly incorrect) ISO-8601 (also see What are valid Date Time Strings in JavaScript?). But other than that, there was no requirement for what Date.parse / new Date(string) should accept other than that they had to accept whatever Date#toString output (without saying what that was).

As of ECMAScript 2017 (edition 8), implementations were required to parse their output for Date#toString and Date#toUTCString, but the format of those strings was not specified.

As of ECMAScript 2019 (edition 9) the format for Date#toString and Date#toUTCString, have been specified as (respectively):

ddd MMM DD YYYY HH:mm:ss ZZ [(timezone name)]
e.g. Tue Jul 10 2018 18:39:58 GMT+0530 (IST)
ddd, DD MMM YYYY HH:mm:ss Z
e.g. Tue 10 Jul 2018 13:09:58 GMT

providing 2 more formats that Date.parse should parse reliably in new implementations (noting that support is not ubiquitous and non–compliant implementations will remain in use for some time).

I would recommend that date strings are parsed manually and the Date constructor used with year, month and day arguments to avoid ambiguity:

// parse a date in yyyy-mm-dd format
function parseDate(input) {

  let parts = input.split('-');

  // new Date(year, month [, day [, hours[, minutes[, seconds[, ms]]]]])
  return new Date(parts[0], parts[1]-1, parts[2]); // Note: months are 0-based
}

Why Does Date.parse gives 000 milliseconds?

Date.parse - parse date from string. When you pass newDate parse method call .toString() from object and result will be output in format like this - Wed Dec 08 2021 16:37:43 GMT+0200 (Eastern European Standard Time). As you can see - there is no milliseconds. According to this in your case Date.parse not gives it.

You can fix it by using constructor Date(your second example). Or you can use method toISOString() that return milliseconds.

Date.parse(new Date().toISOString());

Why can i parse invalid date string?

In fact the problem here is coming from Date.parse() method, if you check:

Date.parse("New Item 3");

It will return:

983401200000

console.log(Date.parse("New Item 3"));

What is the logic behind the string parsing on the Date constructor in javascript for the strings 0 to 110?

from 0 to 4, the value is used for "months" at 6:00

The default offset will be your locale which is -6 during these months.
According to author Ryan Dahl, "Default year is 0 (=> 2000) for KJS compatibility".
You might have noticed that the year changes from 2000 to 2001… I believe this is a bug. See: existing answer

from 5 to 10, the value is again used for "months" but at 5:00 (why?)

11 and 12, the value is "months", but back to 6:00

DST changes in your locale, which is the default offset

from 13 to 31 is an invalid date (why?)

Because the string supplied is not a valid month or YYYY it is parsed as DD and a Date with only a day value doesn't make sense. Why it does not default MM or YY is unclear… Speculating, the reason might be ambiguity between YY and DD, when parsing.

from 32 to 49, now the value belongs to the years: 2000 + the value
(why?)

from 50 to 99, now the value belongs to the years: 1900 + the value
(why?)

PHP's strptime, Python's datetime.strptime and UNIX C's strptime assume that 00-68 years belong to 2000 and 69-99 belong to 1900.
This is intended to be an API convenience, assuming that lower numbers 32:49, closer the current century, are of the current century and that higher numbers 50:99, closer to the previous century, are referring to said century.

from 100 to 110 (and even more, I tried 9999 with the same result) it
belongs to the year, literally: 100 becomes year 0100

YYY (when > 99) is literally YYY AD, akin to ISO-years

But the time, is set to 5 hours, and minutes and seconds belong to my
current computer minutes and seconds (why?)

Timezones do change over time, and the locale parsing will try to account for those.

> (new Date("1883-05-31")).getTimezoneOffset()
350
> (new Date("1893-05-31")).getTimezoneOffset()
360
> (new Date("2023-05-31")).getTimezoneOffset()
300

However, dates prior to Unix epoch never include the timezone's name, and Dates using a North American locale, prior to November 18, 1883 do not use the modern GMT offset as it was not yet established.

> new Date("1883", "10", "18", "12").toString()
'Sun Nov 18 1883 12:00:00 GMT-0550 (Central Standard Time)'
> new Date("1883", "10", "18", "13").toString()
'Sun Nov 18 1883 13:00:00 GMT-0600 (Central Standard Time)'

(The change occurred early noon)

> new Date("1883", "10", "18", "12", "09").toString()
'Sun Nov 18 1883 12:09:00 GMT-0550 (Central Standard Time)'
> new Date("1883", "10", "18", "12", "09", "24").toString()
'Sun Nov 18 1883 12:09:24 GMT-0600 (Central Standard Time)'

Date wrong in JS

2021-07-20 is a valid ISO time. It gets parsed as 20th July 2021 at midnight UCT. It then gets converted to local time for you which (in Porto Alegre) is three hours earlier.

2021-07-20 is not a valid ISO time, so it hits your JS engine's implementation-specific parser for non-standard date formats.

JS Date creating incorrect dates/JS Date confusion

I believe the issue you are facing is the result of malformed date strings (or at least it very well might be). getMonth and day are both numbers which means that when they are less than 10, they will be a single character string. 2022-1-1 is not a valid date for JS to parse. padStart can help format it correctly.

Try:

const date = new Date(`${today.getFullYear()}-${String(today.getMonth() + 1).padStart(2, "0")}-${String(day + 1).padStart(2, "0")}`);

javascript Date.parse and Date.UTC give different results

Date.parse assumes local time if not specified.

The UTC one, however, is obviously UTC.

For example, my computer is UTC -5 (well, Chicago CDT actually), so the two timestamps happen to be 5 hours apart for me.

You will get the same thing if you specify UTC:

Date.parse('8/15/2012 '+'11:59:45 AM UTC'); //1345031985000
Date.UTC(2012, 7, 15, 11, 59, 45); //1345031985000

Why Does Date.Parse Give Incorrect Results