by Michael S. Kaplan, published on 2009/04/08 10:16 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2009/04/08/9537610.aspx
Developer colleague Dmitri asked me:
Hi Michael,
I noticed the MSDN documentation for the calendar IDs claims that
Note The gap in numbering between the identifiers CAL_GREGORIAN_XLIT_FRENCH and CAL_UMALQURA is intentional. The designator for CAL_UMALQURA is 23, not 13.
I am wondering if you are aware of the intention by which this gap was created?
Let me tell you, it is kind of a funny story.
That topic on Calendar Identifiers does indeed have this note.
And the table has a gap that kind of begs for some explanation:
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
One almost wonders where the hidden calendars are, doesn't one? :-)
Well, it all comes down to a mistake that was made many years ago.
Some people might disagree with my characterization of events but I was there and I know I'm right so I'm gonna tell this story my way. If you don't like it then why the hell are you here? :-)
Anyway, it was a mistake.
In Office.
They had taken some empty slots in the LCID table and made some assignments.
Of course Windows had made assignments for some new locales in the same slots.
Since Office back in the earlier part of the decade was shipping much more regularly than Windows, they had already shipped products with these values, so Windows changed its "not yet shipped" values to match the Office ones for these newer locales.
And at the same time a more formal process by which Office and other groups would request values was put in place, so that they would never have this kind of problem come up again.
Now this process had to be put in for calendars, too.
So when Office added their support for the Saka calendar (ref: Oh (Saka to me, Saka to me, Saka to me, Saka to me) Whoa Babe (Just a little bit) A little respect (just a little bit)) and .NET added support for all those other calendars like the Jalaali (ref: Behold the PersianCalendar class) and so on, each one was given a CALID value.
Even if Windows had no formal timeline to support it.
Even if the technology requesting the calendar would never need it.
Even if nobody ended up needing to use it.
Here, in a totally unoffical way, I'll name them all.
Some you may even know where they are.
While others you won't since they aren't anywhere.
Like placeholders, almost:
And after that? Who can say for sure? One never knows what the next valoue might be, or even how (or IF) these placeholders will be used.
For now it is just the items that cause the intentional gap in the list of supported calendars!
The Unicode characters were released from
their original contracts when SiaO went an hiatus; only time will tell
if the Characters Union (AFL-CIO) is willing to negotiate new contracts
for the characters it represents...