5 ms·
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 construct
by notatoad 1y ago
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.
- wewtyflakes 1y agoThose are both big qualifiers... 1. Know not to use the constructor. 2. Make assumptions about user input. Neither seem awesome.
- samwho 1y agoHopefully this quiz helps with the first point :)
- 2muchcoffeeman 1y agoI 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?
- notatoad 1y ago>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.
- bevr1337 1y ago> you just need to never rely on the constructor for parsing user input. A rather large disadvantage in a programming language for developing user interfaces
- deleted 1y ago[deleted]