Japanese Calendar via Program
Carsten Witte
I wrote a little test-program in order to display an emperor formatted
date:
#define LCID_ENGLISH (MAKELCID(MAKELANGID(LANG_ENGLISH, SUBLANG_ENGLISH_US), SORT_DEFAULT))
#define LCID_JAPANESE (MAKELCID(MAKELANGID(LANG_JAPANESE, SUBLANG_NEUTRAL), SORT_DEFAULT))
#define MAX_FORMAT (80)
int _tmain(int argc, TCHAR* argv[])
{
TCHAR szInfo[MAX_FORMAT];
int iReturn= 0;
::GetLocaleInfo(LCID_ENGLISH, LOCALE_SSHORTDATE, szInfo, MAX_FORMAT);
_tprintf(_T("[1] LOCALE_SSHORTDATE EN: \"%s\"\n"), szInfo);
iReturn= ::GetCalendarInfo(LCID_JAPANESE, CAL_JAPAN, CAL_SSHORTDATE,
szInfo, MAX_FORMAT, NULL);
_tprintf(_T("[2] CAL_SSHORTDATE JP: \"%s\" (gg y/M/d ?)\n"),
szInfo);
_stprintf(szInfo, _T("%d"), CAL_JAPAN);
iReturn= ::SetLocaleInfo(LCID_JAPANESE, LOCALE_ICALENDARTYPE, szInfo);
if (iReturn != 0) _tprintf(_T("[3]\tswitched to emperor calendar\n"));
else _tprintf(
_T("[3]\tfailed to switch to emperor calendar (error code %d)\n"),
::GetLastError());
::GetLocaleInfo(LCID_JAPANESE, LOCALE_SSHORTDATE, szInfo, MAX_FORMAT);
_tprintf(_T("[4] LOCALE_SSHORTDATE JP: \"%s\"\n"), szInfo);
return 0;
}
P:\conTest\Debug>conTest.exe
[1] LOCALE_SSHORTDATE EN: "yyyy-MM-dd"
[2] CAL_SSHORTDATE JP: "gg y/M/d" (hopefully "gg y/M/d")
[3] switched to emperor calendar
[4] LOCALE_SSHORTDATE JP: "yyyy/MM/dd"
Now, that leaves me with a question: If indeed the calendar switch for
my LCID_JAPANESE has happend, and CAL_SSHORTDATE indicates the correct
Japanese representation, why is LOCALE_SSHORTDATE still "yyyy/MM/dd"?
Of course this later in my program applies to COleDatetime::Format which
is giving me "2004/08/16" instead of "Heisei 16/8/16".
What am I missing here???
Carsten Witte
--
private: http://www.carsti.de
lurker : http://www.midwinter.de/lurk
Michael (michka) Kaplan [MS]
does not (as your test proves).
Instead you should try using GetDateFormat once you have changed the
calendar....
--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies
Windows International Division
This posting is provided "AS IS" with
no warranties, and confers no rights.
"Carsten Witte" <newsg...@gmx.info> wrote in message
news:ifa1i0plj855d5bkq...@4ax.com...
Carsten Witte
<#9MgAo6g...@TK2MSFTNGP10.phx.gbl>:
>You should not assume that GetLocaleInfo workss off the current calendar; it
>does not (as your test proves).
Shouldn't that be documented to some degree? The whole SetLocaleWhatnot
API suggest that you have some influence on the behavior of a given
locale.
Quite contrary. If you further extend my sample and use the output of
::GetCalendarInfo(LCID_JAPANESE, CAL_JAPAN, CAL_SSHORTDATE, ...);
as an input for
::SetLocaleInfo(LCID_JAPANESE, LOCALE_SSHORTDATE, ...)
you switch the *current* locale for the computer, not the one you have
specified as first parameter for SetLocaleInfo. :(
>Instead you should try using GetDateFormat once you have changed the
>calendar....
This also gives the date as specified in the default of the given
locale: for LCID_JAPANESE it's "2004/08/17" and not the hoped for
"16/8/17", "Heisei" of course omitted due to the English UI.
Is there an API to elaborate form locale date representation to
strftime-formatters? So I could use the output of GetCalendarInfo as an
format-string for COleDateTime? But then, alas, strftime has no
formatter for the year in CAL_JAPAN or has it?
Carsten Witte
Pondering about this (German) thread:
<uSxKppkf...@tk2msftngp13.phx.gbl>
and my problem at hand I realized that using COleDateTime is alltogether
not a really I18N-safe idea. Background: if you use
::GetDateFormat(LCID_JAPANESE, DATE_SHORTDATE, ...);
you'll sure get "Heisei 16/8/17"; Heisei of course replaced by the
corresponding Kanji. But if you rely on
COleDateTime::Format(VAR_DATEVALUEONLY, LCID_JAPANESE);
you'll only get "/8/17". Now, what might be the root cause for that one,
aside from a pssible programming error on my behalf?
My personal interpretation is:
The regular international Features SDK-API somehow understands about the
Emperor Calendar format via *LocaleInfo and LOCALE_ICALENDARTYPE,
CAL_JAPANESE and the lpFormat "gg".
On the other hand COleDateTime::Format utilizes VarBstrFromDate, which
doesn't have a value for VAR_CALENDAR_JAPANESE and _tcsftime which
doesn't have a formatting code like "%g". So even
_tsetlocale(LC_TIME, _T("jpn"));
doesn't help you out on that one. Tested it already. I had a
disturbingly resembling experience when I once programmed against
locale-formatted numbers. As long as you relied on the
internationalization SDK everything is fine, one step towards MFC or
regular C-functions and you're in really deep sh^H^H trouble. And the
automation functions only work in 50% of those cases, too.
Michael (michka) Kaplan [MS]
> Michael (michka) Kaplan [MS] wrote:
> >You should not assume that GetLocaleInfo workss off the current calendar;
it
> >does not (as your test proves).
>
> Shouldn't that be documented to some degree? The whole SetLocaleWhatnot
> API suggest that you have some influence on the behavior of a given
> locale.
It is documented, though admittedly not as well as may be best (I will
follow up on that issue). For the alternate calendar you use
GetCalendarInfo.... or use the GetDateFormat/GetTimeFormat APIs to get the
formats that use the settings.
Note that you can check the LOCALE_ICALENDAR and see your setting worked.
> Quite contrary. If you further extend my sample and use the output of
>
> ::GetCalendarInfo(LCID_JAPANESE, CAL_JAPAN, CAL_SSHORTDATE, ...);
>
> as an input for
>
> ::SetLocaleInfo(LCID_JAPANESE, LOCALE_SSHORTDATE, ...)
>
> you switch the *current* locale for the computer, not the one you have
> specified as first parameter for SetLocaleInfo. :(
This is also by design and described in the documentation -- SetLocaleInfo
only works on the current locale. The initital parametr is "used" only to
verify that the LCID is valid, which is technically a bug but one that
cannot change at this point since it has worked this way for 12 versions of
Windows and would almost certainly break applications.
> >Instead you should try using GetDateFormat once you have changed the
> >calendar....
>
> This also gives the date as specified in the default of the given
> locale: for LCID_JAPANESE it's "2004/08/17" and not the hoped for
> "16/8/17", "Heisei" of course omitted due to the English UI.
If your user locale is changed to Japanese and the alternate calendar is
changed?
> Is there an API to elaborate form locale date representation to
> strftime-formatters? So I could use the output of GetCalendarInfo as an
> format-string for COleDateTime? But then, alas, strftime has no
> formatter for the year in CAL_JAPAN or has it?
I do not know enough about how well COleDateTime interacts with non-default
user locales and non-default calendars....
Michael (michka) Kaplan [MS]
bias toward them in both knowledge and support. So of course I think they
are better than other technologies. It does make sense that COM in general
does not have info for calendars that do not have explicit support like
Hijri, Thai Buddhist and Gregorian.
--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies
Windows International Division
This posting is provided "AS IS" with
no warranties, and confers no rights.
"Carsten Witte" <newsg...@gmx.info> wrote in message
news:cat3i01fuejlkdc6r...@4ax.com...
Carsten Witte
<eBuWP1Fh...@tk2msftngp13.phx.gbl>:
>It is documented, though admittedly not as well as may be best (I will
>follow up on that issue).
Yipp, oh so many information is well hidden in subordinate clauses.
>This is also by design and described in the documentation -- SetLocaleInfo
>only works on the current locale.
D'oh! Now that you mention it, I actually see it in the first sentence
of that very help page.
ms-help://MS.MSDNQTR.2004JUL.1033/intl/nls_7w1b.htm
Think I alwas have been distracted by the API desciption, especially the
first parameter. ...and loads of wishful thinking.
>The initital parametr is "used" only to
>verify that the LCID is valid, which is technically a bug but one that
>cannot change at this point since it has worked this way for 12 versions of
>Windows and would almost certainly break applications.
What's with renaming it to "LCID Reserved" or "Ignored"? Many API use
that term to indicate parameters with no current meaning.
>> This also gives the date as specified in the default of the given
>> locale: for LCID_JAPANESE it's "2004/08/17" and not the hoped for
>> "16/8/17", "Heisei" of course omitted due to the English UI.
>
>If your user locale is changed to Japanese and the alternate calendar is
>changed?
On the Japanese systems it's fine all the time. It was merely about
writing functionality that works for all systems. With the SDK functions
I get the expected results.
>I do not know enough about how well COleDateTime interacts with non-default
>user locales and non-default calendars....
I now gave up on COleDateTime alltogether, as illustrated in the other
thread.
Carsten Witte
>Well, I am on the team that owns the Platform SDK NLS functions so I have a
>bias toward them in both knowledge and support. So of course I think they
>are better than other technologies.
Still it's very confusing to have like three functions claiming to do
the same thing and coming up with different results. I think the NLS
group should work together with e.g. COM and .NET groups in order to
have a common basis for NLS support thruout the system. OTOH I know how
hard it is to get such a thing. I'm really looking forward to what
happens to these scenarios in the C# world.
>It does make sense that COM in general
>does not have info for calendars that do not have explicit support like
>Hijri, Thai Buddhist and Gregorian.
Actually VarBstrFromDate does feature parameters for VAR_CALENDAR_HIJRI,
VAR_CALENDAR_THAI, and VAR_CALENDAR_GREGORIAN. Only the Japanese
calendar is left out for no apparent reason. So COleDateTime is excused
for simply being a wrapper to an probably incomplete support within COM.
Michael (michka) Kaplan [MS]
> Still it's very confusing to have like three functions claiming to do
> the same thing and coming up with different results.
Well, two different results among the three. :-)
> I think the NLS
> group should work together with e.g. COM and .NET groups in order to
> have a common basis for NLS support thruout the system.
We actually also own the .NET "NLS" functionality....
> OTOH I know how
> hard it is to get such a thing. I'm really looking forward to what
> happens to these scenarios in the C# world.
They actually work better as you can do work outside the context of the
currentuser settings such as you would like here.
> >It does make sense that COM in general
> >does not have info for calendars that do not have explicit support like
> >Hijri, Thai Buddhist and Gregorian.
>
> Actually VarBstrFromDate does feature parameters for VAR_CALENDAR_HIJRI,
> VAR_CALENDAR_THAI, and VAR_CALENDAR_GREGORIAN.
Isn't this what I just said? Perhaps I should have put a comma after support
and replaced "like" with "such as the supported". :-)
> Only the Japanese calendar is left out for no apparent reason.
Well, there are other calendars also left out there. It takes a lot to
implement a calendar generically across many different ones....
> So COleDateTime is excused
> for simply being a wrapper to an probably incomplete support within COM.
It is not a wrapper -- it is an entirely separate implementation which has
to work even when the support is not available on the platform.
Carsten Witte
>We actually also own the .NET "NLS" functionality....
So there is hope, yet.
>Well, there are other calendars also left out there. It takes a lot to
>implement a calendar generically across many different ones....
They should simply ask you for input then. Looks like the SKD got it
right, so the COM team should benefit from that. Or that's one way to
coax us into the .NET world. ;)
>> So COleDateTime is excused
>> for simply being a wrapper to an probably incomplete support within COM.
>
>It is not a wrapper -- it is an entirely separate implementation which has
>to work even when the support is not available on the platform.
I still consider COleDateTime a wrapper for the various Var*Whatnot
functions (as most of the MFC is some sort of an API-wrapper even tho it
has a buch of self-contained functionality). It becomes more or less
evident if you look at atlcomtime.h line 316 where COleDateTime::Format
is directly calling VarBstrFromDate. So, never try to run an MFC program
that is utilizing COleDatetime w/o having your trusty ole*.dll in place.