Doc for GtkCalendar: http://developer.gnome.org/gtk/2.24/GtkCalendar.html
General explaination for zero based:
The use of zero to start counting is actually an optimization trick from Assembly programmers. Instead of assigning 1 to the count register, they XOR'ed the register with itself, which was slightly faster in CPU cycles. This meant that counting would start with 0 and would always be up to the length of elements, excluding the last one.
Also, the use of zero is also popular with pointer arithmetics where you would use one base pointer pointing at some allocated memory, plus a second pointer which would be at an offset from this base pointer. Here, using the value zero makes a lot of sense to point the offset to the base of the memory block. (General array logic tends to be the base address plus the offset x record size.)
And zero-based month numbers? Often, many programming environments calculate the data as a number of days since some default data. December 31, 1899 is a popular date, although there have been plenty of other dates used as base date. All other dates are offset from this base, and will just be stored as one single number. Fractions would be used to indicate hours, minutes and seconds, where 0.25 would be 24/4 = 6 hours. Thus, to transform a date into a real date, all the environment has to do is transform this number into a real date.
However, the combination of zero-based arrays and 1-based month values does bring a problem. To get the month name of month 9, you would have to get item 8 from the month array. Some developers would be happy with decreasing the month number before getting it's name. Others preferred to change the month into something zero-based since people just want to know the name, not the number. It's a personal view.
Moreover, there is more than a reason why one could think there is wrong with Date/Calendar:
- Surprising bases (1900 as the year base in Date, admittedly for deprecated constructors; 0 as the month base in both)
- Mutability - using immutable types makes it much simpler to work with what are really effectively values
- An insufficient set of types: it's nice to have Date and Calendar as different things, but the separation of "local" vs "zoned" values is missing, as is date/time vs date vs time
- An API which leads to ugly code with magic constants, instead of clearly named methods
- An API which is very hard to reason about - all the business about when things are recomputed etc
- The use of parameterless constructors to default to "now", which leads to hard-to-test code