MSDN Blogs

There are several LCTYPE values suitable for use by GetLocaleInfo and GetLocaleInfoEx that act as abbreviations.

Like the seven LOCALE_SABBREVDAYNAME* values representing the days, which are documented as:

Native abbreviated name for [Day]. The maximum number of characters allowed for this string is 80, including a terminating null character.

Or like the twelve LOCALE_SABBREVMONTHNAME* values representing the months, which are documented as:

Native abbreviated name for [Month]. The maximum number of characters allowed for this string is 80, including a terminating null character.

And there are helpful doc topics like Day, Month, Year, and Era Format Pictures that say things like:

d	Day of the month as digits without leading zeros for single-digit days.
dd	Day of the month as digits with leading zeros for single-digit days.
ddd	Abbreviated day of the week as specified by a LOCALE_SABBREVDAYNAME*value, for example, “Mon” in English (United States).
dddd	Day of the week as specified by a LOCALE_SDAYNAME* value.
M	Month as digits without leading zeros for single-digit months.
MM	Month as digits with leading zeros for single-digit months.
MMM	Abbreviated month as specified by a LOCALE_SABBREVMONTHNAME* value, for example, “Nov” in English (United States).
MMMM	Month as specified by a LOCALE_SMONTHNAME* value, for example, “November” for English (United States), and “Noviembre” for Spanish (Spain).

Very helpful, right?

Well, they might have done a few abbreviated other language examples, but I suppose we can guess what they might be. No harm, no foul….

Any developer can wrap their head around these examples and this information.

Go for it, developers!

Oh, wait — before I forget, there are some problems with going forward with this knowledege here.

Like the not insignificant number of locales that don’t have abbreviated names that are any different than the regular month names.

So (for example) many locales will have a LOCALE_SABBREVDAYNAME5 that is identical to LOCALE_SDAYNAME5, a LOCALE_SABBREVMONTHNAME10 that is identical to LOCALE_SMONTHNAME10. And so on.

They don’t want to mention that? Seems like oit ought to be in there somewhere….

It may certainly put a cat among the pigeons for some unususpecting developers!

Oh yeah, and it gets worse.

Like let’s look at the Japanese abbreviated month names:

1
2
3
4
5
6
7
8
9
10
11
12

Um, wait.

Isn’t that what M (Month as digits without leading zeros for single-digit months) is supposed to be for? That’s just unexpected.

We do not’ document that either — even though we’ve been doing it for years!

And there are other strange examples, too. Perhaps you have a favorite?

There is of course what we do for zh-CN abbreviated and full month names:

1?	??
2?	??
3?	??
4?	??
5?	??
6?	??
7?	??
8?	??
9?	??
10?	??
11?	???
12?	???

Just keep in mind in that ? is “month” and you are pretty much reading Chinese now, right?

Now I’m not saying it’s wrong — it is right, but it is odd if you are not Chinese to think of the difference here as being abbreviated versus full month names.

Remember what we have for the Japanese abbreviated month names? We have the same thing for Korean — oh, and also Czech and Slovak, too!

1
2
3
4
5
6
7
8
9
10
11
12

I am fully prepared to assume that this different approach might be expected in East Asia.

But that it might also be in Slovakia and the Czech Republic too? That’s new information!

It is hardly my first intuitive guess that those are the expected abbreviations for these Czech and Slovak month names, right?

leden	január
únor	február
b?ezen	marec
duben	apríl
kv?ten	máj
?erven	jún
?ervenec	júl
srpen	august
zá?í	september
?íjen	október
listopad	november
prosinec	december

Now all I know is that if I am a developer I have a somewhat foggy notion of what MMM means.

Any developer or designer trying to create a calendar might.

But for many locales, it clearly ought to be documented in some conceptual topic that I should be ready to assume that MMM might be MMMM. Or even M!