- cross-posted to:
- [email protected]
- [email protected]
- cross-posted to:
- [email protected]
- [email protected]
cross-posted from: https://programming.dev/post/33754840
new Date(“wtf”)
You must log in or # to comment.
It is awesome, in the same way a planet killer asteroid heading straight for us is awesome!
This quiz was stressful. Like, there were so many times when I knew I was being cued up for a trick question, but I still fell for it.
It’s a mess. Expectation is always wrong, basically.
In the process of being replaced.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal
JavaScript has had the
Dateobject for handling date and time since its first days. However, theDateAPI is based on the poorly designedjava.util.Dateclass from Java, which was replaced in the early 2010s; but, because of JavaScript’s goal of backward compatibility,Datesticks around in the language.Damn, I thought you meant JavaScript itself was being replaced.
One can only
undefined
Hmm, I can believe that it was based on
java.util.Date, but I don’t remember that being as unpredictable. I guess, a different API to begin with, would have avoided a lot of problems, though…
You do not, under any circumstances, “gotta hand it to javascript”.
Love this quiz btw
Best laugh I’ve had in a while. That is some grade-A jank.
Have you seen https://www.destroyallsoftware.com/talks/wat
Classic
I have now, that’s fantastic!
Luckily the new Temporal API is shaping up.
I quite like this one.
Ah, JavaScript…
Ok, I get that the Date API is problematic, but I wouldn’t expect anything meaningfull from
new Date("not a date").getTime()anyway. Why would you in the first place?Because reasonable APIs have input validation provided out of the box, so that not everybody has to reinvent the validation wheel (inevitably incorrectly).
It’s mainly horrid, because it means you have to code extremely defensively (or I guess, use a different API).
You can’t rely onnew Date("not a date")aborting execution of your function by throwing an error. Instead, you have to know that it can produce anInvalid Dateobject and check for that. Otherwise a randomNaNshows up during execution, which is gonna be extremely fun to try to find the source of.I understand that it’s implemented like that partially for historical reasons, partially because it’s often better to display “NaN” rather than nothing, but it’s still the sort of behavior that puts me in a cold sweat, because I should be memorizing all kinds of Best Practices™ before trying to code JavaScript.
Parsing user input? Nonsense data coming from an API?
If you’re expecting shit data then you’d have unit tests for those cases so you’d know what to expect.
Maybe you don’t expect shit data; you just get it. I know, always expect it…
You think you’d get an error from the constructor.
Until the new Temporal API comes along, there are some libraries we can use.
- luxon
- dayjs
- or compile chrono (Rust) to WebAssembly
