1609401 - Inconsistent date object - Negative year in result

Status: RESOLVED DUPLICATE of bug 1439800

(Core :: JavaScript: Standard Library, defect)

Description

[ChrisColeman34]

Attachment: ffb.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.117 Safari/537.36

Steps to reproduce:

Attempting to create a new date using the format "DD-MMM-YYYY" has inconsistent results across multiple machines.

In the JS console type new Date("20-Jan-2020");
Hit enter and view the resultant object

Actual results:

Seems to be interpreting the year component as a negative year on some machines rather than the correct year (see screenshots).

Date return seems to either be Mon Jan 2020 or Sun Jan 20 -2020 this seems to differ based on machine / network however I have been unable to find out why.

Expected results:

see screenshots - date formatted correctly, in this example the year is somehow -2020 rather than 2020 on some machines, this seems to occur for all years when found.

Comment 1

[ChrisColeman34]

Please note, I am aware the date format is non-standard however I cannot address that at this time, I am more looking to understand the variation between machines and to see if there is a setting that I am missing which could resolve this issue.

Comment 2

[Seba S.]

Hi, ChrisColeman34,

Thanks for your contribution!

I could reproduce the described behavior in:

Windows 10
Firefox Nightly 74.0a1 (2020-01-20) (64-bit)
Firefox 72.0.1 (64-bit)

I don´t know if this behavior is correct so I will be assigning product and component so we can keep on track. If you have anything else to add please feel free to append it here on a thread.

Regards,

Comment 3

[André Bargull [:anba]]

When Date() is called without new, that's the case for "Friend's Firefox" in the attached screenshot, the current time is returned as a string and any input arguments are ignored. In the specification this case is defined here when NewTarget is undefined.

The other case is already reported at bug 1600902, so I'll close this report as a duplicate.