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/Help...L-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 Houwing
jesse.houwing at sogeti.nl

Jesse Houwing wrote:
> 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

> 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.


--
Mihai Nita [Microsoft MVP, Visual C++]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email

* Peter Duniho wrote, On 14-1-2010 0:58:
> Jesse Houwing wrote:
>> 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

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

--
Jesse Houwing
jesse.houwing at sogeti.nl

Jesse Houwing wrote:
> 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

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

---
frmsrcurl: http://msgroups.net/microsoft.public...tains-13-items