You are right, it is a relatively minor tripping hazard. JS has lots of those. But it is one that I tripped over recently. :)
The unexpected behavior is that simply changing the separator character changes the result. Most of the time, users will consider common date separators like hyphen and slash interchangeable. Now I have to either write extra code to remediate that expectation or confuse users when it does not work as expected (bad UX, and a non-option).
Also, my locale does not use that date notation. I would be surprised if JS Date parsing took locale into consideration.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
As much as I hate native Date handling in Javascript, this one doesn't strike me as especially bad (at least not worse than the rest of Date).
Without specifying a time part, it assumes 0:00:00. Sounds fine.
Using your locale notation, it assume local client timezone.
Using ISO 8601 notation "yyyy-mm-dd", it assumes UTC timezone.
The basic problem is that you can't ignore timezones in JS when dealing with abstract dates which don't have time info with them (like a birthday).
In C# for instance you can deal with datetimes with "Unspecified" offset.
You are right, it is a relatively minor tripping hazard. JS has lots of those. But it is one that I tripped over recently. :)
The unexpected behavior is that simply changing the separator character changes the result. Most of the time, users will consider common date separators like hyphen and slash interchangeable. Now I have to either write extra code to remediate that expectation or confuse users when it does not work as expected (bad UX, and a non-option).
Also, my locale does not use that date notation. I would be surprised if JS Date parsing took locale into consideration.