The WinForms DateTimePicker and MonthCalendar do not support culture settings

by Michael S. Kaplan, published on 2005/03/28 02:19 -05:00, original URI:

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)

# Michael Kaplan on 28 Mar 2005 7:44 AM:

The constants I gave above are defined in the main NLS header file in tha Platform SDK: winnls.h; sorry I did not give the reference.

# Anand on 7 Apr 2005 11:16 PM:

This is a big problem when using Windows Forms. We moved from ASP.NET to Windows forms for a specific project now and am now stuck with this bug.:-(

# Michael S. Kaplan on 7 Apr 2005 11:26 PM:

Sorry about that.... I feel your pain (as someone who has had to write calendars in the past!). But the APIs in the System.Globalization class give the plumbing that makes those things possible, much moreso than anything in Windows....

# Brad Eck on 16 Jun 2005 4:30 PM:

Do you know if this will be dealt with in the next release (2.0)?

# Michael S. Kaplan on 16 Jun 2005 7:04 PM:

Hi Brad,

As the post indicated, this is a Windows issue, not a .NET Framework one. So there is no way it *could* be fixed in Whidbey. They are Shell Common Controls.

Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.

referenced by

2011/12/30 We call 'em ShortestDayNames for a reason; they're as short as they're EVER gonna be!

2006/11/19 'Son, your TextBox is writing checks that your EDIT control can't cash'

2006/07/24 Our highly internationalized OS uses DPI, aka Dots Per In-.... um, never mind!

2005/12/21 New in Windows Vista: updates to clock and calendar

2005/10/27 The WinForms Common Dialogs do not support culture settings

2005/04/01 Simplification is not necessarily grounds for canonization; ask the IMEMode property!

go to newer or older post, or back to index or month or day