Calendar Assumptions: Why does Windows (or .Net) have 13 month names?

  • Article

Sometimes people have wondered why DateTimeFormatInfo.MonthNames returns an array of 13 months, or why there's a LOCALE_SMONTHNAME13.  The answer is that some calendars have 13 months.  The MSDN Calendar.GetMonthsInYear() has an example of when "leap" months are used in some calendars.

Microsoft.Net could have decided to return only 12 months for the Gregorian calendar, however it returns an empty 13th month, even when such months aren't used by a particular calendar.

Its worth remembering that non-Gregorian Calendars may do things that someone used to only the Gregorian calendar may not expect.  Obviously calendars may have different numbers of months, but they also may have other interesting aspects:

  • Different numbers of months
  • Different arrangements of weeks
  • Calendars may start on different days of the year (ie: not the same day as the Gregorian January 1.)
  • Some calendars may start on different days each year, or even have periods that are considered part of two years.
  • Some calendars may have Eras that are much shorter or longer than Gregorian.  Eg: the Japanese Eras.
  • Some calendars are much newer than Gregorian with years < 100, others are older with years > 4000.
  • Many calendars have extra cultural or religious aspects.
  • Calendars such as Hijri have adjustments that may be difficult to predict.

When testing software with such calendars its good not to make too many assumptions.  Similar to the Gregorian leap year, some events may be difficult to encounter or test.  Narrow assumptions (February only has 28 days) may miss the rarer event (a leap year with 29 days.)  In general its good to make as few assumptions as possible about the users date or time expectations and let the OS or the Framework handle details.

Calendars have also been added (UmAlQara in Windows Vista and .Net Framework 2.0), so its possible that future users of your current software may encounter different calendars that you can test today.  Trying to avoid cultural assumptions and avoiding making expectations will make your applications more robust in the future.