As is usual with these JS critiques, the problem is that you'd never do most of this. Yes, it's silly, but nobody passes random strings into the date constructor because all you really need to know is that the date constructor does weird shit with random strings.
You don't need to burn it, you just need to never rely on the constructor for parsing user input. It all works fine as long as you know the structure of the data before you pass it in.
I don’t think this is a very good defence.
Let’s say you started a date lib right now that would take random strings and do its best.
Suppose you identify the string is only integers. What logic needs to be applied to make the example I pointed out make any sort of common sense?
>Let’s say you started a date lib right now that would take random strings and do its best.
why would you do that? that's a bad idea, and no matter what implementation you choose you will end up with some silly compromises like javascript has in it's date constructor. javascript's default choices are probably no better or worse than whatever choices you would make.
if you're writing a date parser, the first thing you should do is come up with a better definition than "take random strings and do your best" unless you're putting an LLM behind it.
Those are both big qualifiers... 1. Know not to use the constructor. 2. Make assumptions about user input.
Neither seem awesome.