by Michael S. Kaplan, published on 2006/02/08 03:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2006/02/08/527375.aspx
Last month I talked about GetDateFormat and using the DATE_LTRREADING/DATE_RTLREADING flags with it in Return of the Mark.
Now, there is a lot going on here when we are deciding issues of directionality. So let us try to separate all of the issues. :-)
I mean to say, if you are a developer calling GetDateFormat it is hard to know whether to pass one of the flags.
And depending on the context of where the formatted string is being inserted and what is in the string, those marks could be important to include.
If you think it sounds like another case of a bad decision to put localization decisions in the hands of developers like I pointed out in Just when you think you know a function... then you are insightful.
Unfortunately, you are also mistaken, since there is much more involved than localization here; there is the calendar being used, the needs of various locales, and the context where it is inserted. And there is no good way to put this one in the hands of localizers and get the right results, either.
Because they do not have all the information.
Basically, we have all of the following information contributors on the 'directionality' front:
Ok, so we have four factors to consider in our decision for whether to pass DATE_LTRREADING or DATE_RTLREADING, and if so, which one to pass.
All of which GetDateFormat could do itself if there were some cool flag like DATE_PICK_APPROPRIATE_READING_PLEASE, or somesuch. :-)
And how would you get the calendar that is being used? Well, if DATE_USE_ALT_CALENDAR is passed to GetDateFormat, you would use GetLocaleInfo with the LOCALE_IOPTIONALCALENDAR flag; otherwise, you would use GetLocaleInfo with the LOCALE_ICALENDARTYPE flag.
So, how would you get the directionality from a locale? Well, you can get that from the LOCALESIGNATURE returned by LOCALE_FONTSIGNATURE (more on that parameter this post and this one), looking at bit 123 of the Unicode Subset Bitfields.
And how do you combine these two possible locale settings and the calendar setting?
Hmmm, that is a bit harder, isn't it?
Actually, it turns out that things are fairly easy, believe it or not.
The main trick to remember is that the markers are used to imply directionality in the case where directionality may be unclear.
If all three are RTL, then obviously you could include DATE_RTLREADING (if you were also sure that the user default locale was also RTL you could perhaps pass no flags since there is no ambiguity, it is a pure RTL context).
If any of the three are RTL, then let the calendar decide (which means that CAL_HEBREW and CAL_HIJRI lead to DATE_RTLREADING, other CAL_* leads to DATE_LTRREADING, and CAL_GREGORIAN is decided by the UI language.
Otherwise, you could pass DATE_LTRREADING (and once again if the default user locale was also LTR you could perhaps pass no flags since there is no ambiguity, it is a pure LTR context).
Now if I had an interview candidate who had some real NLS experience, this might have made a fascinating interview question, I think.
And figuring out the logic above would have made an excellent conceptual question for a lunch interview! :-)
In any case, GetDateFormat could almost certainly be smarter here.
It is very hard for the caller to know what to do, while most of the information is available to the function -- it is a shame it is not set up to do the work if it is asked to.... :-(
This post brought to you by U+200f, RIGHT-TO-LEFT MARKER
referenced by