Windows is too busy being consistent with the user to be consistent with itself!

by Michael S. Kaplan, published on 2008/05/14 10:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/05/14/8502723.aspx

The mail that came on the other day was:

We’re seeing an issue that doesn’t seem correct to me, but I just wanted to confirm. In debugging the issue, the developer found that operating system shows the special genitive month name for Hebrew locale and Hebrew lunar calendar only.  Does the Hebrew lunar calendar even have special genitive month names? We don’t think so. 

Can you shed any light on why Windows would show the special genitive month name only  when the user locale is Hebrew and calendar is Hebrew lunar?  Is there something we’re calling incorrectly? A Windows bug? ???

Thanks so much for your help,

The repro steps were then provided, but those aren't to relative here. :-)

First, and most importantly, Hebrew does not have genitive month names, or any kind of genitive form that would impact dates. In fact, looking at the Wikipedia on the Hebrew language:

Hebrew grammar is partly analytic, expressing such forms as dative, ablative, and accusative using prepositional particles rather than grammatical cases. However, inflection plays a decisive role in the formation of the verbs and nouns. E.g. nouns have a construct state, called "smikhut", to denote the relationship of "belonging to": this is the converse of the genitive case of more inflected languages. Words in smikhut are often combined with hyphens. In modern speech, the use of the construct is sometimes interchangeable with the preposition "shel", meaning "of". There are many cases, however, where older declined forms are retained (especially in idiomatic expressions and the like), and "person"-enclitics are widely used to "decline" prepositions.

There is also a link to more information that explains there is (in a sense) a genitive case -- but if you look at how it is constructed you will see why dates in general and month names in particular are affected.

The interesting issue here is that even though

• people on one side were pretty insistent in explaining that Hebrew had no genitive case here
• there were people on the other side who were equally insistent that there must be one

since they were seeing the same apparent net effect -- different format strings used in calls to GetDateFormat with the same date values returning different month names.

Interesting conclusion, right? Not terribly accurate, but still kind of astute!

Now I have talked about genitive forms a lot in the past:

And I wonder whether one or more of them contributed here. In all of those posts I have never gotten too deep into how they are constructed in language.

I probably will talk about this at some point, though not today, since it is not relevant to the problem this team was seeing. :-)

The problem here had a very different cause....

I'll give you a hint what it is.

Consider the blog .NET is too busy being consistent with Windows to be consistent with itself...., noting that this is not the actual problem here, though the root cause is similar.

You see, in that blog, the discussion is about how the calendar chosen by the user in Regional and Language Options is causing the calendar being used by the CurrentCulture in the .NET Framework to not be the new, cool default calendar in .NET. The user preference overrides things.

This bug in the reported Hebrew case was that the month names were being retrieved by several different ways, including calls to GetDateFormat with format strings like "mmmmdd" vs. "mmmm" (which on the surface is a a great way to detect genitive month name usage!). And one other small difference:

The use of LOCALE_NOUSEROVERRIDE in some cases but not others.

That simple difference, combined with (from the original report) "when the user locale is Hebrew and calendar is Hebrew lunar", means that when the LOCALE_NOUSEROVERRIDE flag is passed the Gregorian month comes out; when the flag is not, the Hebrew lunar month comes out.

Just like the user wants!

This will give us דצמבר (December) versus כסלו (Kislev) and so on.

Our "non-genitive" form. :-)

The actual code difference between the two cases feels quite natural, because after all there are performance benefits to using LOCALE_NOUSEROVERRIDE when you can get away with it.

Who would say no to reasonable performance enhancements?

And we don't tend to think about things like month names changing, so it seems like a great candidate for optimization. Only in this case, it isn't, so much. :-(

You can even see it in managed code in those same circumstances where the user locale choices cause the data to be handled/interpreted differently. Just like what was described in .NET is too busy being consistent with Windows to be consistent with itself....

And if you want to avoid those different month names, remember to call the functions more consistently!

This blog brought to you by כ (U+05db, aka HEBREW LETTER KAF)

referenced by

go to newer or older post, or back to index or month or day