> So instead of documenting it in a single place, your argument is to document it in dozens or hundreds of places and somehow that'll never get out of date. Eve

> So instead of documenting it in a single place, your argument is to document it in dozens or hundreds of places and somehow that'll never get out of date. Even though the single documentation in a single place must be assumed out of date? When the documentation lives alongside the actual concrete use cases, it at least tends to get fixed when those individual concrete use cases are changed. > How do you know what is January? Is it 0? 1? Or something else entirely because someone thought it'd be cute to use the value of "JAN" since, after all, that 4 byte string perfectly fits in a 4 byte int. You didn't read the documentation I linked I see. "The month component, expressed as a value between 1 and 12." - this rules out fourcc nonsense, this rules out 0, this leaves only 1. > Holy shit look at that obscene effort and obscurity! 0-based? Nice curveball number #1. Someone will probably refactor it to make it 1-based later, so that's nice curveball number #2 that will break all to/from int casts for interop. Or fix them - lets be honest, someone's going to cast (Month)some_var_that_is_1 for interop and expect January, and then probably cast back to (int)month for more interop, resuling in bugs canceling out bugs. I've also seen similar enums get accidentally reordered by someone fat-fingering Alt when pressing up-arrow, swapping lines, changing the values, for curveball #3... hope it gets caught in code review! It won't if such a typo sneaks into the initial version, but one can dream! So now I gotta read more than you could bother to type out... > Quick, what's the order of those arguments? Year month day. Easily verified by intellisense, too, since we're clearly okay with that in-thread. Your code will throw ArgumentOutOfRangeException. Someone will add these kinds of overloads for "convenience" even if you have a Month enum too BTW, so don't pretend that it's existence fixes things. I can totally get behind named arguments: new Date(year: 2020, month: 10, day: 5) Or "named" constructors: Date.FromYearMonthDay(2020, 10, 5) Either of which I'd prefer over: new Date(new Year(2020), Month.October, new Day(5)) Programmer style YYYYMMDD isn't that bad either, honestly. But, even with that last one: What the heck is the timezone? UTC? Local timezone of the executing machine? Timezone of whatever machine is interpreting the Date instance? I'm gonna have to read the docs regardless...