Hi,

Thanks for letting me know. You are right that it is a bug as it was displaying the wrong month, but your solution is incorrect as it would only work for en-US and not other cultures.

The problem was occuring in DateTime.Parse because by default it will use the culture of the currently executing thread. The culture to use is determined by the browser language settings not the server, though the server can be configured to force a culture rather than use the browser culture.

If you look in Web.config you'll see this:

<globalization
culture="auto:en-US"
uiCulture="auto:en-US"
requestEncoding="utf-8"
responseEncoding="utf-8"
fileEncoding="iso-8859-15" />

The "auto:" part tells the server to use the preferred culture as determined by the browser, but if resources for that language are not available it will fall back to the default which is specified after the colon.

So, in this case, its was your browser set to en-GB, not the server. I was able to produce the same symptom on this site by changing my browser language to en-GB. So the DateTime.Parse was not correctly determining which part was the month because in en-GB its backwards from en-US.

I have made the correct fix here that respects the culture but displays the correct month in all cases.

DateTime selectedMonth = DateTime.Now;
try
{
selectedMonth = new DateTime(year, month, 1);
}
catch(Exception)
{}

this.litHeader.Text = Resource.BlogArchivesPrefixLabel
+ selectedMonth.ToString("MMMM, yyyy");

Using the constructor new DateTime(year, month, 1), there is no ambiguity which number is the month as with .Parse(...)

So this fixes the problem without forcing en-US

I will have this fix in svn trunk by tonight.

Best,

Joe