Hacker News Reader

Comment by lukan | Hacker News Reader

"If you're passing raw/unvalidated user input to the date parser you're holding it wrong."

Exactly. I would have never thought about using the Date class in this way. So the behavior is pretty much wtf and local time can get pretty complicated, but I wouldn't expect to get the right time, when passing some vague strings.

View on HN

The entire point of a parser is to parse unknown values. That's the entire job of a parser: take unstructured (usually string) data and turn it in to something structured, such as a date. If it can't do that reliably with error reporting then it's not a good parser on a very fundamental level.

There are so many valid and reasonable cases where this will bite you.

"Real-world data" from CSV files or XML files or whatnot (that you don't control) and sometimes they have errors in them, and it's useful to know when instead of importing wrong data.

You do something wrong by mistake and getting wrong/confusing behaviour that you literally never want, and then you need to debug where that's coming from.

The user gives you a date, you have no idea what they entered and you want to know if that's correct.

A parser is supposed to reject invalid input, not generate semi-arbitrary outputs.

I agree on a theoretical level, but this is javascript and the web we are talking about. Invalid input is rather the norm in genereral, with the expectation the browser should still display something.

But I do dream of a alternative timeline, in where the web evolved different.

Let's say you're setting an appointment. The user puts in nonsense, so you helpfully schedule an appointment for a nonsense date (thank you so much, we'll get right to that in -124 years). Instead of... catching a parsing error and asking the user to try again or something? It's wild that a nonsense date would be considered for any purpose at all in a user-centric system.

Then again, I don’t think you pass user input directly into a date constructor in any language, in practice.

You decide on the format that makes sense for the user, you validate the input against that format, and then you map it into a native date.

If the date constructor supports the format you want, it’s only coincidence that makes that final mapping step simpler.

So, the native date constructor having weird behavior on invalid strings doesn’t really change real world code.

If you really ask me, I don't build forms that accept strings as dates from users. There is a date picker element, that can be restricted and validated.

You still need to do some validation of the input because it's difficult to impossible (in many cases) to be absolutely sure the input you receive only comes from your validated form. Even code running entirely within the browser can receive broken/malicious input from an extension, user script, or even the host OS.

It can be a bit belt and suspenders doing validation of specific forms but shit happens. It's much better to catch stuff before it's persisted on the back end or on disk.

That's why I wrote, "validated"

And there can also be man in the middle attacks or whatever, the efforts you do for validation depends still on your task at hand. How critical an error would be.

But even for the most trivial tasks I would never think of passing some user strings to Date and expect to get a valid value.

Reply on news.ycombinator.com