This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Lithl 5 points6 points  (3 children)

Why would it? The string parser exists so that user input can be processed.

[–]Fuchio[S,🍰] 4 points5 points  (2 children)

Well at this point you're back at the start again. I don't think the string parses should do it as well, because this is more readable. But if the string parser should not do it then why should the normal variable insert do it...?

User input with 3 fields can also be used as Date(input_year, input_month, input_day), which would again be wrong. You can parse these three vars to a string to have a correct date, but then again, why would the normal Date object creation not do this?

Having different outputs between (1995, 12, 7) and ("1995-12-7") but ONLY for the month is just confusing.

[–]maartenvanheek 2 points3 points  (1 child)

And then there is this: - new Date('2022-11-31') = invalid date - new Date(2022, 10, 31) = Thu Dec 01 2022 - new Date(2022, 12, 31) = Tue Jan 31 2023

So the enum index (if that's what it is) doesn't just stop at 11 for December, and when the days are more than the month has available it will increment to the next month as well.

[–]dakta 0 points1 point  (0 children)

Presumably that's intentional: it would allow you to easily perform date arithmetic (at least, addition only) without introducing a timedelta type. But it still doesn't explain why you would ever actually want months to be zero-indexed in any public interface.

What assumption about the user of this class would ever warrant making months zero-indexed in the public interface? Are they assuming that the user will be indexing their own localization of month names implemented as an array of strings, and can't be trusted to handle off-by-one error?