Prev: "Detours" problems
Next: fclose and CreateFile are very slow on some machines
From: Corinna Vinschen on 18 Feb 2010 06:34
Hi,


In calendar systems supporting era strings, the EnumCalendarInfo and
GetCalendarInfo functions return the various era strings (CAL_SERASTRING)
as well as the year in which the eras start (CAL_IYEAROFFSETRANGE) in
terms of the gregorian calendar.

However, eras don't always start exactly at the gregorian calendar year
break. For instance, the current era in the CAL_JAPAN calendar, Heisei,
started on 1989-01-08, the one before, Showa, started on 1926/12/25.

It seems that the internal calendar functions know this. Calling
GetDateFormat for 1926/12/24 returns the japanese equivalent for
"Taisho 15/12/24", calling it for 1926/12/25 returns the equivalent for
"Showa 1/12/25".

Unfortunately, there seems to be no function or calender type
information which returns the exact date of an era start. I can't find
anything besides CAL_IYEAROFFSETRANGE, which appears to be a bit...
fuzzy.

Did I just not look closely enough or is there really no function
returning this information?


Thanks,
Corinna

--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
From: Mihai N. on 20 Feb 2010 01:17
> Did I just not look closely enough or is there really no function
> returning this information?

You looked well, but the info is not public.
There are some new requstry keys in Win 7, undocumented, that might help.
But overall the Win API to deal with alternate calendars is vrey weak.


--
Mihai Nita [Microsoft MVP, Visual C++]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email

From: Mihai N. on 20 Feb 2010 16:11
> There are some new requstry keys in Win 7, undocumented, that might help.

That would be "registry" :-)

You can read more here:
http://msdn.microsoft.com/en-us/library/ee923790%28VS.85%29.aspx
and here: http://blogs.msdn.com/shawnste/archive/2009/09/24/japanese-
calendars-how-do-i-test-support-for-additional-eras.aspx

But the key contain extra eras, beyond what the system already knows,
so it can be use to add eras, but not to retrieve info about the
"default" ones.



--
Mihai Nita [Microsoft MVP, Visual C++]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email

From: Corinna Vinschen on 21 Feb 2010 05:06
Mihai N. wrote:
>> There are some new requstry keys in Win 7, undocumented, that might help.
>
> That would be "registry" :-)
>
> You can read more here:
> http://msdn.microsoft.com/en-us/library/ee923790%28VS.85%29.aspx
> and here: http://blogs.msdn.com/shawnste/archive/2009/09/24/japanese-
> calendars-how-do-i-test-support-for-additional-eras.aspx
>
> But the key contain extra eras, beyond what the system already knows,
> so it can be use to add eras, but not to retrieve info about the
> "default" ones.

Thanks for the pointers.


Corinna

--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
From: Corinna Vinschen on 21 Feb 2010 05:11
Mihai N. wrote:
>> Did I just not look closely enough or is there really no function
>> returning this information?
>
> You looked well, but the info is not public.
> There are some new requstry keys in Win 7, undocumented, that might help.
> But overall the Win API to deal with alternate calendars is vrey weak.

I agree. I don't understand why a function exists which only returns
a year but not an exact date. What's the problem to return exact
information?


Corinna

--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
 |  Next  |  Last
Pages: 1 2
Prev: "Detours" problems
Next: fclose and CreateFile are very slow on some machines