by Michael S. Kaplan, published on 2010/03/31 07:01 -07:00, original URI: http://blogs.msdn.com/michkap/archive/2010/03/31/9986458.aspx
Regular reader and collation hero of days past Santhosh Pillai asked over in the Suggestion Box:
Question: Does Windows 7 provide OS level support for any non-Gregorian support, such as switching your calendar?
Also, are there any online calenders that you know of that support non-Gregorian other than (Google Calendar)?
Of course I am assuming the question goes beyond the calendars mentioned in Calendar Identifiers:
Calendar identifier Meaning 1 CAL_GREGORIAN Gregorian (localized) 2 CAL_GREGORIAN_US Gregorian (English strings always) 3 CAL_JAPAN Japanese Emperor Era 4 CAL_TAIWAN Taiwan calendar 5 CAL_KOREA Korean Tangun Era 6 CAL_HIJRI Hijri (Arabic Lunar) 7 CAL_THAI Thai 8 CAL_HEBREW Hebrew (Lunar) 9 CAL_GREGORIAN_ME_FRENCH Gregorian Middle East French 10 CAL_GREGORIAN_ARABIC Gregorian Arabic 11 CAL_GREGORIAN_XLIT_ENGLISH Gregorian transliterated English 12 CAL_GREGORIAN_XLIT_FRENCH Gregorian transliterated French 23 CAL_UMALQURA Windows Vista and later: Um Al Qura (Arabic lunar) calendar
But I'm actually not sure what else there might be.
Switching the current calendar is as easy as a SetLocaleInfo call with the appropriate LOCALE_ICALENDARTYPE from the table above.
Beyond that? The pickings are pretty slim.
I mean, it was over five years ago that I pointed out the whole Calendars on Win32 -- just there for show.... thing.
So all of these calendars, they don't have full OS level support, which means parsing and formatting and using even if it's not the current calendar....
If that is what the question is about, the answer is a simple no. Because no such support exists....
Well, wait.
Technically, that isn't completely true.
There are some functions added to do calendar-type stuff, though they are marked deprecated and no header/lib file information is provided for them. You can see them in the National Language Supporty Functions list:
Function Description AdjustCalendarDate Deprecated. Adjusts a date by a specified number of years, months, weeks or days. ConvertCalDateTimeToSystemTime Deprecated. Converts a specified CALDATETIME structure to a SYSTEMTIME structure. ConvertSystemTimeToCalDateTime Deprecated. Converts a specified SYSTEMTIME structure to a CALDATETIME structure. GetCalendarDateFormatEx Deprecated. Retrieves a properly formatted date string for the specified locale using the specified date. GetCalendarSupportedDateRange Deprecated. Gets the supported date range for a specified calendar. IsCalendarLeapYear Deprecated. Identifies whether the specified year is a leap year within the given era for the specific calendar. UpdateCalendarDayOfWeek Gets the day of week that corresponds with a specified day and populates the DayOfWeek field in the given CALDATETIME structure.
That last one is deprecated too, you can see if you look at the topic; they just forgot to mark it in the table like the others.
Hmmmm. Interesting set of functions, huh? :-)
These functions were added in Vista, as part of the work to support the updates to clock and calendar.
And presumably they could, by their existence, provide a way for .Net to support the ability to synthesize a calendar if Win32 supported one that .Net didn't know about. Though this might be something of a theoretical thing for now since as stagnant as calendars may be, it is clearly .Net that has gotten more new stuff, more recently....
These functions are supported in Windows 7, by the way. And in Server 2008 R2.
They provide a means to avoid one of the only other ways to do calendar stuff on the non-default calendar -- to switch the calendar.
For now, I'd say this is as close as you can get to the full OS support, though of couse parsing is still needed for "full" to be full enough....
# Michael S. Kaplan on Wednesday, March 31, 2010 6:54 AM:
The more functional the title, the less satisfied I am with it. This seems like a valuable prinicple to me....