Comment by 2muchcoffeeman
Comment by 2muchcoffeeman 2 days ago
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.
Comment by 2muchcoffeeman 2 days ago
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.
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.
> 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.