by Michael S. Kaplan, published on 2008/07/10 10:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/07/10/8715940.aspx
The question I got the other day was:
I am using GetCalendarInfo on Windows 2008 Server to get the CAL_SSHORTDATE and the format that it returns is not the format I set using intl.cpl->”Customize this format”->”Date Tab”->”Short Date:”. It always returns the default format, irrespective of what I set it to. When using GetLocaleInfo to get LOCALE_SSHORTDATE, I get the correct value. For the comparison purposes I made sure that the calendar ID that I pass to GetCalendarInfo is the ID of the calendar type that I set in intl.cpl. Is this a known issue with GetCalendarInfo or am I missing something? I couldn’t find much information about retrieving customized data in MSDN. I see this issue not for a specific case, but all the times when I invoke GetCalendarInfo. I do not set the CAL_NOUSEROVERRIDE flag. I have tried it for different LCIDs and for CAL_SLONGDATE too. It always returns the default date format. I am running Windows server 2008 on ia 64. This issue was first seen when the user locale was set to Japanese(Japan) and when I queried for the CAL_SSHORTDATE format of the calendar with id 1 and the lcid 1041.
But as I have mentioned, it happens for other calid, lcid and caltype combinations too. Please let me know if anything else is needed.
I honestly had no ideas, what was going on. So my response indicated as much:
Looking at the docs, GetCalendarInfo will in theory care about where or not the CAL_NOUSEROVERRIDE was set -- and thus (again, in theory) would care about the custom calendar setting. But I don't know what actually happens here in practice....
But I was sure to include Shelby on the mail, since she does tend to know as lot about calendar support than me. :-)
Her response made me realize I was giving GetCalendarInfo too much credit here:
The short answer – the behavior that you are seeing is by design.
Instead, use GetLocaleInfo to get the date format picture (e.g. dd/MM/yyyy), or GetDateFormat to get a formatted date string (e.g. 07/09/2008). Even better – you should use the name-based APIs: GetLocaleInfoEx and GetDateFormatEx because they support custom locales.
More Details:
- CAL_SSHORTDATE is not a user-overridable value, and therefore, GetCalendarInfo returns the DEFAULT date format for each valid LCID/Calendar combination. For the purposes of GetCalendarInfo, the only user-overridable item is CAL_ITWODIGITYEARMAX.
- When changing date formats in intl.cpl, you are really changing the LOCALE settings, not the CALENDAR settings. This is not at all intuitive, and our docs are definitely lacking on this point. I’ll remind myself to follow up on this with the doc team.
Well, if it is the design then I guess it is the design.
But in that case I do think it is a design flaw.
I mean after all (as I have discussed before in blogs like SetLocaleInfo really stinks), SetLocaleInfo is lame because (among other reasons) it takes a locale, validates it, and then if it is not the current user default, it ignores the locale you pass.
And have no doubt, that behavior is LAME.
But then take SetCalendarInfo, which is even worse since it is just as bad with the additional problem that it won't even affect the current user default locale's settings!
That is turning the lame up to ELEVEN, if you know what I mean.
Hell, the documentation goes on about all of the valid locales -- including a nice blurb about custom locales -- which are basically ignored anyway.
And as a bonus it explains how you can pass CAL_USE_CP_ACP, which is useless in SetCalendarInfo anyway....
Not that GetCalendarInfo is much better -- as the original question and answer make clear.
Need more proof?
Well, the CAL_TWODIGITYEARMAX flag, the only useful flag you can really pass since CAL_USE_CP_ACP is crap here?
It has nothing to do with calendars or locales at all -- the CALID and CALTYPE parameters are also in there for lame duck purposes only (in Win9x they had extra validation steps but served no functional purpose).
And even though you are passing a number, no CAL_SET_NUMBER flag exists -- so according to the documentation you have to convert your number to a string first, for no useful purpose.
Thus the title (a slight misquote from Gorky Park).
and Kirwill's answer to the detective is applicable here too: no point, that's the point.
The functionality to set this one attribute could have been one function with one INT parameter to set the value, rather than what was used instead.
Talk about a function that's looking kinda dumb with its finger and its thumb in the shape of an L on it's forehead!
This blog brought to you by L (U+004c, aka LATIN CAPITAL LETTER L)
Clarks on 10 Jul 2008 10:11 AM:
For the comparison purposes I made sure that the calendar ID that I pass to GetCalendarInfo is the ID of the calendar type that I set in intl.cpl. Is this a known issue with GetCalendarInfo or am I missing something? I couldn’t find much information about retrieving customized data in MSDN
Michael S. Kaplan on 10 Jul 2008 12:01 PM:
You have to avoid GetCalendarInfo to get customizations -- it does not support them, by and large. You aren't missing anything, but the function is. :-)