The issue is partially described in the Microsoft Knowledge Base (article 889834) but this article does not tell the full story (and some of what it tells is wrong).

Let's start with the title and its problems between CurrentUICulture and CurrentCulture:

The DateTimePicker control and the MonthCalendar control do not reflect the CurrentUICulture property of an application's main execution thread as you expected when you created a localized application in the .NET Framework or in Visual Studio .NET

Now the MonthCalendar and the DateTimePicker are not based on the UI settings, they are based on the user settings. So even if the control is fully globalized, it would never be based on the UI settings. This is because the date, time, calendar, number, currency, and collation settings are always based on the default user locale (and on CurrentCulture in the .NET Framework). If a localized application's language were to match this, it would only because the user happened to set CurrentCulture and CurrentUICulture to be the same culture, which is often the case but does not have to be.

Now the article is smart enough to point out the user locale settings control the language of the DateTimePicker and the MonthCalendar controls, and it does point out why -- because these two controls are wrappers around the Windows Shell common controls.

But this is not the full story.

Because calendars, as imperfect as they are in Win32 (cf: Calendars on Win32 -- just there for show...., Calendars on Win32 -- Not all there yet) and .NET (cf: Calendars.NET -- new platform, new issues) both platforms have serious advantages over the Shell controls, since the Shell DateTimePicker and MonthCalendar common controls only support the Gregorian calendar.

Thus even if your default user locale settings include a calendar setting where GetLocaleInfo with the LOCALE_ICALENDARTYPE returns any of the following values:

Value Constant                     Meaning                                     
1     CAL_GREGORIAN                Gregorian (localized)
2     CAL_GREGORIAN_US             Gregorian (English strings always)
3     CAL_JAPAN                    Year of the Emperor (Japan)
4     CAL_TAIWAN                   Taiwan calendar
5     CAL_KOREA                    Tangun Era (Korea)
6     CAL_HIJRI                    Hijri (Arabic lunar)
7     CAL_THAI                     Thai
8     CAL_HEBREW                   Hebrew (Lunar)
9     CAL_GREGORIAN_ME_FRENCH      Gregorian Middle East French calendar
10    CAL_GREGORIAN_ARABIC         Gregorian Arabic calendar
11    CAL_GREGORIAN_XLIT_ENGLISH   Gregorian Transliterated English calendar
12    CAL_GREGORIAN_XLIT_FRENCH    Gregorian Transliterated French calendar

the DateTimePicker and MonthCalendar controls will never go beyond the Gregorian calendar.

Now the methods and properties on the calendar classes derived from Calendar class (GregorianCalendar, HebrewCalendar, HijriCalendar, JapaneseCalendar, JulianCalendar, KoreanCalendar, TaiwanCalendar, and ThaiBuddhistCalendar) contain the capabilities to let you create your own calendar. I'll try and throw such a sample of a calendar together another time.

Note that the above limitations do not apply to the ASP.Net control (System.Web.UI.WebControls.Calendar). I will cover this control and its capabilities another day....

 

This post brought to you by "ฟ" (U+0e1f, THAI CHARACTER FO FAN)