[tffgg]

Why would you want that? It is super confusing since 1~first as well as every real life date representation I know has 1=January

[globular-toast]

Because it only needs to be "1" when you format it for human consumption. 0-based is much easier to work with internally.

[cunthorpe]

No it doesn’t. Dates aren’t meant to be worked with as raw numbers, so the utility of 0-based numbers is gone and now you only have February ending on day number 27

[globular-toast]

If people don't work with them as numbers then the argument is completely moot. All you need is timestamps, deltas and formatting functions.

How many days is in the delta 1 hour? 1? or 0?

[IshKebab]

The whole reason months start at zero is because somebody wanted to work with them as raw numbers.

[cunthorpe]

Yes and they were wrong. There’s a whole “misconceptions programmers have about dates” you might want to read. The only number for dates is the Unix timestamp.

[globular-toast]

So if I want to have a style per month or something in my program, I'm wrong? If I want to select the next month's style I have to do something awkward like `(current mod 12) + 1` instead of the more natural `(current + 1) mod 12`?

[dspillett]

Then why do days not start from 0. If that argument is value it should be applied consistently so 2000-01-01 is day=0, month=0.

[kevin_thibedeau]

0-based months were meant to assist with lookups in 0-based arrays.

[globular-toast]

Probably because the ancients didn't have a strong grasp on the number 0.

Midnight is zero. What's confusing about the number of days starting from 0 too?

Why do we use months? No sane internal representation stores the number of months. They are completely and utterly useless and exist only in printed representations of dates.

[jcranmer]

Props to the Mayans, whose dates are (almost) a base-20 number counting from the Mayan date of creation. It's not fully base 20, because the 2nd digit only counts to 18 because 360 is close enough to a year. So 13.0.5.17.19 is followed by 13.0.6.0.0 instead of 13.0.5.18.0. Bonus points: no leap years to worry about!

The downside is that their full calendar is somewhat more complicated, so they would say that today is (checks) 13.0.8.11.11 8 Chuwin 9 Sek, and tomorrow is 13.0.8.11.12 9 Eb' 10 Sek (that Tzolkin calendar component doesn't work like our months do!).

[dspillett]

I was meaning in the context of JavaScript, where the first day is 1 and the first month is 0.

A case can be made for either 0 (for consistency with time representation) or 1 (to go with the defacto standard of how most if us bipedal meatsacks process dates) but there must have been alcohol or something stronger involved when the current date object came into being.

[globular-toast]

Erm... nobody was arguing for it being the current way. That's retarded. This whole thread is about making them both 0-based rather than both 1-based.

[lexicality]

> 0-based is much easier to work with internally.

Why's that?

[petepete]

Even if it was I'd still want days and months to start at one and, you know, match everything else in existence that represents them.

[globular-toast]

Mainly because you can use normal modulo arithmetic and use them as array indices.

But as I mentioned in another comment, really you should be touching the internals of the datetime object at all. It's a mistake to do something like `myDatetime.day += 1`. You should instead do `myDatetime + timeDelta(days=1)` or something.

So it shouldn't matter whether it's 0-based or 1-based at all. But since it apparently does (I don't know why), then it might as well by 0-based like everything else.