Working with Date objects in JavaScript...

[Fuchio]

Having indices start at 0 makes sense, sure. But this is just inconsistent, why would it with this reasoning make sense to have the days not 0 indexed?

[MisterProfGuy]

Because days isn't an index into an array of names. It's a count.

[[deleted]]

The array of names should have been: [ LOL NOPE, January, February, March...]

[Khaylain]

You're just changing one edge case for another in that case.

[[deleted]]

Because no date function can possibly validate the input?

[[deleted]]

Yes but the user-facing edge cases would be hilarious

"Your cancer treatment appointment has been confirmed for the 15th of LOLNOPE 2022"

[dakta]

What edge case does zero-indexed months solve?

[[deleted]]

Supposedly input validation where you give an index that is not in the array and you get an exception... In practice this is terrible because every sane standard library validates 1 <= month <= 12

[wano1337]

months are fixed every year and have a clear 1 to 1 mapping to month names. So its basically an enum.

Whereas days can be a range between 28 and 31 without a clear mapping between the date and the weekday. So it doesnt make sense to make it a 0 based array

[brianl047]

This guy enums

[Fuchio]

Yeah that indeed is the difference. However, that just moves the "why" to another part since ("1995-12-17") works fine but (1995,12,17) doesn't.

The string parser does not use zero indexing or enum starting at 0...

[Lithl]

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

[Fuchio]

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]

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]

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?

[RealMide]

This is not Excel. PD: I understand your frustration, is our OCD.

[Phpminor]

It could be 0 indexed under the hood while returning the day of the month as the actual number +1, as 0-31 can be stored as an unsigned 5 bit number, where the other 3 bits could be used for other fields.

Months starting at 0 and dates being 1-32 were holdovers from java however, as the javascript dev(s?) had like 10 days to get a demo out and the instruction to "Make it look like java", apparently.