3 ms·
Lots of surprises here! The general theme seems to be that the parser is very eager to find some interpretation of the input as a date, even in ways that appear
by schoen 1y ago
Lots of surprises here! The general theme seems to be that the parser is very eager to find some interpretation of the input as a date, even in ways that appear pretty unprincipled, even in circumstances where human users would probably not agree with the interpretation, and even though it does have ways that it could signal errors. Though maybe some of the weird cases actually do trace back to unusual real-world use cases!
- 2muchcoffeeman 1y agoThe problem is that you couldn’t start to guess all of these. It’s just random noise. Strings 32-49 are in the 2000s but 50 onwards are in the 1900. Burn it and start again.
- spiffytech 1y ago> Burn it and start again Good news! The builtin Temporal API is on its way. It's widely regarded as a solid API, learning from some of the best time APIs in other languages. In terms of parsing, it looks like Temporal only accepts RFC 9557 strings (an extension of ISO 8601 / RFC 3339). Anything else throws an exception.
- zelphirkalt 1y agoBad news: shitty designed parts are here to stay, because people will cry for backwards compatibility.
- pavel_lishin 1y agoSure. But people don't have to keep using them. Of course... they will. Because there are going to be more outdated results on search engines for Date, instead of the Temporal API. But at least there's something positive coming!
- notatoad 1y agoAs 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
- malux85 1y agoYeah this is the curse of the intermediate developer at work The junior developer experiences nothing but errors, and struggles to get something over the line The intermediate developer adopts “reduce errors at all cost” mentality and their parsers are too helpful, they make too many assumptions, and you end up with the Date class type behaviour. The senior developer knows the deadliness of this, and designs a robust class that behaves consistently and errors early on invalid input.
- stevage 1y agoI can sympathise with the urge to write code that produces a valid answer if at all possible. Usually I can overcome that urge. It's curious that these designers could not.