{recycled joke here} It could have been called LOCALE_SSINGLESERVINGDAYNAME*

by Michael S. Kaplan, published on 2011/01/27 07:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2011/01/27/10120308.aspx

The other day, colleague Gwyneth asked:

Is there a date mask for SSUPERSHORTDAYNAMES?
 
NLS Name Date Mask Value
SDAYNAMES dddd
SABBREVDAYNAMES ddd
SSUPERSHORTDAYNAMES ?
 
Thanks,
Gwyneth

The quick answer here is simple.

No.

And the slightly longer answer is also pretty straightforward:

No, there is no date mask that will make use of the LOCALE_SSHORTESTDAYNAME* Constants.

Of course the slightly longer answer is kind of candy-ass, and on top of it there is a prescriptivist passive/aggressive style correction on the field in question.

Kind of obnoxious of me, I'm sorry about that.

How about I give the full answer now?

Background:

Sometimes it can be hard to remember the original reasons that a feature was implemented in Windows, even though those very reasons may have guided the way that the feature was designed and any limitations thereof.

Now we don't make the situation any easier by not really documenting any of this, either. In essence we leave the average developer to look at the design and guess what we had in mind.

And as a special non-bonus, if a developer wants to design something that the implementation doesn't allow, they get to be really frustrated at being left out of the "blessed locus of supported scenarios."

For the less snarky answer, you can look to blogs of mine like Size matters (when it comes to day names, at least),

The full answer:

By most any honest, objective measure, the attempt to take the LOCALE_SMONTHNAME* Constants and the LOCALE_SDAYNAME* Constants and provide shortened versions of them via the respective LOCALE_SABBREV* Constants was and is an unmitigated disaster.

Because there are a number of languages that do not tend to, as a matter of course, abbreviate such words. Thus many of the providers of locale data for those specific locales returned the same values for the abbreviated month and day names as they did for their full brethren and said we do not abbreviate those terms.

But just because of this situation does not mean there was no scenario in mind -- there is!

I mean if you are building a little calendar, for example:

then you must have a shorter name for the days is you want them to fit in this kind of grid.

So we had some meetings.

And in those meetings we had some conversations.

Out of those conversations we had a spec for seven new LCType values, whose original spec'ed names were the LOCALE_SONELETTERDAYNAME* constants.

We were sending a firm message to everyone providing locale data that these fields were gonna be small.

If languages like Hebrew wanted to have day names like יום א and יום ב (compared to their full day names like יום ראשון and יום שני), they were going to see us truncate their day names and each of them would look identical. And they would look really dumb.

And it was by this kind and gentle method of brute force persuasion that we forced everyone to consider this bold new scenario of the calendar view when they came up with a very very very short day name.

Eventually we started calling them two-letter day names because lots of people didn't like even like

S  M  T  W  T  F  S

for English due to the potential Saturday/Sunday and Tuesday/Thursday confusion.

These people who were complaining were forgetting about the scenario though -- no one would confuse the meanings in the context of a calendar!

But we gave in -- first calling them LOCALE_STWOLETTERDAYNAME* constants and then finally the LOCALE_SSHORTESTDAYNAME* Constants.

For some locales a few of them are even three letters, like Hungarian's

H  K  Sze  Cs  P  Szo  V

Though it is of note that both Cs and Sz are unique sort elements in Hungarian, so these were being used more because that is how Hungarian users think of letters than for disambiguation as was the case in English.

As an interesting corollary, a part of our hardcore sell and push where we pointed out that we wanted to use the LOCALE_SABBREV* Constants for this purpose but too many locales weren't cooperating. At this point, LOCALE_SABBREVDAYNAME1 had an implied meaning of "abbreviate if you ordinarily would" that no one wanted to change. Many locale data owners actually ignored that implied meaning and updated their abbrevidated day names to match their shortest day names!

For the record, we neither encouraged nor supported such a change since whn it aws done it amounted to a change in the semantic of the LCType, which is why we wereaddiong a whole new type in order to avoid anyway. Though some locales did it anyway (like Hebrew).

I described this phenomenon previously in They pushed out of the formatt[ing|er].

Eventually, all of this led to an important question that the original spec did not address because we were all so focused on our bloodthirety imperalistic scenario that no one thought of it:

What token should we use if we want to put these "one letter day names" in date format strings?

We had a bunch of rules for how dates and months were grabbed already, as in this table:

We were clearly making use of items that mapped to LOCALE_SDAYNAME1 and LOCALE_SABBREVDAYNAME1 with dddd and ddd, respectively.

The program manager who owned the spec rattled off ideas we quickly shot down, from ddddd to changing the meaning of d or dd, before we went back to the original scenario and said these are for calendars, notr for date formats.

This time, lacking an elegant technical solution (everyone hated the alternatives), this firm line in the sand stuck.

And now we are here, with no way to represent the shortest day names in format strings....

I'll bet you many of you are wishing you had just taken the short answer now!

Cheong on 27 Jan 2011 5:26 PM:

referenced by

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