DateTimeFormat.MonthNames contains 13 items???

  • Thread starter Thread starter Jesse Houwing
  • Start date Start date
J

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();
}
 
Jesse said:
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...
Click to expand...

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
 
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...
Click to expand...


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.
 
* 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
Click to expand...

Makes sense... Though they could have returned an array with the correct
size without problems... Ohh well :)...
 
Jesse said:
Makes sense... Though they could have returned an array with the correct
size
Click to expand...

True. But…
without problems...
Click to expand...

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
 
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
 
Back
Top