DateTimeFormat.MonthNames contains 13 items???

[Jesse Houwing]

Hmz...

I just found a little article on the Daily WTF and tried one of the
samples. And then I found that DateTimeFormat.MonthNames is actually 13
long... WHY?!

Is it to support different calendars? Is it to support 1 based indexes
in VB? I cannot wrap my head around it...

the article in question:
http://thedailywtf.com/Articles/Helpful-SQL-Helpers.aspx

The simplest solution I found:
public static string[] GetMonthNames(int startMonth)
{
var months = new
List<string>(DateTimeFormatInfo.CurrentInfo.MonthNames.Take(12));
return
months.Skip(startMonth).Concat(months.Take(startMonth)).ToArray();
}

 

[Peter Duniho]

Hmz...

I just found a little article on the Daily WTF and tried one of the
samples. And then I found that DateTimeFormat.MonthNames is actually 13
long... WHY?!

Is it to support different calendars? Is it to support 1 based indexes
in VB? I cannot wrap my head around it...

The documentation makes clear it's the former. From the documentation
for DateTimeFormatInfo.MonthNames:

When this property is set, the array must be
one-dimensional and must have exactly 13
elements. Calendar objects accommodate
calendars with 13 months.

Pete

 

[Mihai N.]

I just found a little article on the Daily WTF and tried one of the

samples. And then I found that DateTimeFormat.MonthNames is actually 13
long... WHY?!

Is it to support different calendars? Is it to support 1 based indexes
in VB? I cannot wrap my head around it...

There are years with 13 months in some non-Gregorian calendars.
For instance the Hebrew calendar has a "leap month" in 7 years out of 13.

 

[Jesse Houwing]

* Peter Duniho wrote, On 14-1-2010 0:58:

The documentation makes clear it's the former. From the documentation
for DateTimeFormatInfo.MonthNames:

When this property is set, the array must be
one-dimensional and must have exactly 13
elements. Calendar objects accommodate
calendars with 13 months.

Pete

Makes sense... Though they could have returned an array with the correct
size without problems... Ohh well ...

 

[Peter Duniho]

Makes sense... Though they could have returned an array with the correct
size

True. But…

without problems...

Not necessarily. Second-guessing API design is fraught with error.

You (and I) have no idea what led to the "always 13 elements" decision.
It's entirely possible that requirement was inherited within .NET from
some factor outside their control, such as an unmanaged API, and perhaps
even a factor where it really does make more sense for the length of the
array to always be fixed.

I doubt that the existing design was chosen completely arbitrarily.

In any case, it is what it is.

Pete

 

[Jehuda]

It's very simple guys: look for calender reform at wikipedia and you'll understand. There are models of calendars based on 13 month instead of 12