Comment by schoen 2 days 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!
> 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.
Bad news: shitty designed parts are here to stay, because people will cry for backwards compatibility.
Sure. 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!
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.
Those are both big qualifiers... 1. Know not to use the constructor. 2. Make assumptions about user input.
Neither seem awesome.
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.
Yeah 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.
The 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.