by Michael S. Kaplan, published on 2008/12/08 10:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/12/08/9183424.aspx
There is an old expression about how when it is time to railroad, people railroad (I've mentioned this issue before).
Others think of this as the plate of shrimp theory (if they are fans of the movie Repo Man, that is -- if so, they are cool).
Anyway, Marc had a question from a customer, back in the beginning of October of this year:
Customer wants to display the Era string of the Japanese Imperial Calendar in formatted date string.
If the user default language is set to Japanese with the Japanese Imperial Calendar selected as the calendar in the regional and language options control panel applet then the following highlighted line of code works fine. It provides the formatted Imperial Japanese date.
int nLen = GetDateFormat(0x411,0,0,_T("MM/dd/yyyy gg"),NULL,0);
TCHAR* ptszNewDate = new TCHAR[nLen];
ret = GetDateFormat(0x411,0,0, _T("MM/dd/yyyy gg"),ptszNewDate, nLen);
but if the user default language is set to US English then this no longer works.
If I replace the highlighted line with the following code,
ret = GetDateFormat(0x411,DATE_USE_ALT_CALENDAR,0, _T("MM/dd/yyyy gg"),ptszNewDate, nLen);
Then I get the Imperial Date along with the Era string. But the problem with this is that the docs say (see http://msdn.microsoft.com/en-us/library/ms776293.aspx ) you should only use dwFlags (2nd parameter) that are zero with an lpFormat (4th parameter) that is not null.
But in the above case I am using non-zero dwFlags with non null lpFormat. Is this a bug in the API or the Docs or just coincindence?
The following line returns the complete date in the default format of the Imperial Japanese calendar.
ret = GetDateFormat(0x411,DATE_USE_ALT_CALENDAR,0, NULL, ptszNewDate, nLen);
Now you might wonder why I emphasized when the question was asked.
Well, if you go back to the end of September of this year and find my It used to be right, dammit!, which answers the question -- it is a bug in the documentation.
Now as I mentioned in It used to be right, dammit!,this bug has been present for years. and no one ever noticed it.
Or if they did, they never reported the documentation bug.
I myself have probably reviewed that topic a half dozen times myself over the years for doc reviews, and never noticed the problem.
And I am not the only one in that position.
So how is it that two entirely separate cases of people working with a function find the same bug within ten days that thousands (tens of thousands? more?) never saw before?
A lattice of coincidences?
I guess it was time to run over a plate of shrimp with a train.
This blog brought to you by 𒀁 (U+12001, aka CUNEIFORM SIGN A TIMES A)
Mihai on 8 Dec 2008 12:57 PM:
Let's hope that it will come a time when the calendars story will be cleaned in the Windows world.
The current APIs are more than insufficient (let's remember Office setting the calendar for all the application just to be able to do some work).
And not only is the API insufficient, but even the existing one is "damaged".
What do you get when using DATE_USE_ALT_CALENDAR with a Japanese customized to use imperial date? And Imperial formatted date (not an "imperial date" :-) !
It looks like the "alt_calendar" means "the calendar other than the Gregorian one", not "the calendar other than the current one"
Yes people, if I set my system to Japanese - Imperial calendar, I have no way to get a Gregorian format!
:-)
Michael S. Kaplan on 8 Dec 2008 3:28 PM:
Actually, the calendar story in the managed world is also horked (albeit in different ways). I hope one day both are fixed, though this seems to be staying horked for now....
referenced by
2008/12/09 Yes, Virginia, there is a plate of shrimp