by Michael S. Kaplan, published on 2011/07/12 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2011/07/12/10185373.aspx
No, this is not a blog about Microsoft's newest review model. For that, you can paste in the description of the previous three systems, each of which was best able to allow for the best possible evaluation of all employees!
If you have seven constants:
that you can pass to GetLocaleInfoW/GetLocaleInfoEx, it would to some people be entirely reasonable to think that LOCALE_SDAYNAME1 will return the first day of the week for a given locale.
While others would expect that each value has an absolute identity attached to a particular day of the week.
If one was implementing an internationalization library, there are pros and cons to each method, and when combined with LOCALE_IFIRSTDAYOFWEEK, each of these two methods is entirely derivable from the other.
Now which one a developer might prefer is most often directly related to the way that helps them solve their particular issue, and of course there in the naive sense there is a 50% chance they'll end up being unhappy with how it is implemented in NLS.
All those years ago, the decision was made to check behind door #2.
Looking across all of the locales in Windows, here is how LOCALE_IFIRSTDAYOFWEEK is distributed:
Day | # of locales |
Sunday | 65 |
Monday | 127 |
Tuesday | 0 |
Wednesday | 0 |
Thursday | 0 |
Friday | 1 |
Saturday | 17 |
Of course some of these are in all likelihood wrong, as blogs like Worked like a dog trying to make Tuesday Wednesday? Maybe he just needed Windows. And Bollywood tend to indicate. But overall, the general trend of the way they are distributed is clear.
But as for whether NLS should have been designed in a way that makes LOCALE_SDAYNAME* more dynamic, it is really too late to even call it a bug. After more than 15 years and more than 15 versions of Windows (95, 95 OSR2, 98, 98 SE, Me, NT 3.1, NT 3.5, NT 3.51, NT4, 2000, XP, 2003, Vista, 2008, 7, 2008 R2), the design is what it is.
And this issue is the design....
Raymond Chen - MSFT on 12 Jul 2011 7:51 AM:
Maybe if they had started with LOCALE_SDAYNAME0. Or called them LOCALE_SDAYNAME1984JAN01, LOCALE_SDAYNAME1984JAN02, ... Or just LOCALE_SDAYNAMESUNDAY.
Michael S. Kaplan on 12 Jul 2011 7:58 AM:
They could define new constants like LOCAE_SDAYNAMESUNDAY. No backcompat hit as long as they keep the old ones defined. That's what they did when they tried to clean up all the language/region name stuff previously.
Michael S. Kaplan on 12 Jul 2011 8:35 AM:
They just have to do it better than they did last time (ref).
Mihai on 12 Jul 2011 3:10 PM:
> Of course some of these are in all likelihood wrong
Of course, all those not using Monday as first day are wrong ;-)
Or putting it another way: Why can't they just use Monday?
:-)
Michael S. Kaplan on 12 Jul 2011 3:48 PM:
There's >60 places that disagree!
Markus on 13 Jul 2011 3:41 AM:
Of course, hard-coding a 7-day week is the *real* problem. There do exist non-7-week calendars in real use today (e.g. en.wikipedia.org/.../Javanese_calendar).
If the locale structure just defined methods to "get number of days in a week" and "get array of weekday names", maybe developers would be more disinclined to hard-code weekday assumptions.
Michael S. Kaplan on 13 Jul 2011 8:39 AM:
We don't support the Javanese language as a locale, or any calendar with more than a 7-day week. Perhaps that is the real problem, though I'd have a hard time coming up with the justification based on user requests for that support in computers (which has not to date ever been made)....