by Michael S. Kaplan, published on 2010/03/28 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/03/28/9986185.aspx
This is not a blog about my social life or love life. I'm just saying....
Over in the Suggestion Box, Ian Boyd asked:
I'm short on DATETIME.
Is there, or why is there no, LOCALE_SSHORTDATETIME?
There's a formatting string for short dates, LOCALE_SSHORTDATE (e.g. 3/18/2010). There's a formatting string for times, LOCALE_STIMEFORMAT (e.g. 9:08:13 AM). But there's no locale formatting string that combines a date and time together.
Is it safe to construct a full Date+Time as the date, following by a time, separated by a single space? It this true in all locale's, in LTR and RTL, etc?
There's several questions in there, I'll take them one at a time....
To answer the first question first -- there is no such combinatorial beast of date and time in Win32.
Dates and times are handled separately, despite the almost religious fervor about avoiding overlapping tokens in dates and times (that fervor is mostly an effort to avoid confusion and in English really only affects MINUTES and MONTHS).
And to answer the third question second, about whether it is safe to combine two of the existing ones, yes it is "safe" in that you won't physically hurt anyone by combining the two (that is all .Net does when it combines things, for what it is worth).
One could occasionally confuse users a tad given random factoids like the mostly left-to-right-ness of the Hebrew short date, but by and large they'll know what is going on, so it's fine.
I'll have to cover that issue about Hebrew another day!
And finally, to answer the second question third, the question of "why not?", there is an obvious and easy answer....
Since Win32 has supports for dates and times in two different functions, there is no place one could use such a thing as a LOCALE_SSHORTDATETIME! Thus if it existed it would just be there to make people ask where they could use it since there is no function that can take it as input!
Could a new function have been added? Of course.
But then it begs the question -- if one wants this for a log file or whatever, one can just concatenate the two values, it isn't like the new function would be doing any kind of unique work here that blocks developers, right? :-)
Now if you stretch the "why?" question back to wonder why things were designed that way in the first place, you'd have to ask a bunch of people who made decisions nearly 20 years ago. Only one of those people reads this blog as far as I knod, and even she probably only does so occasionally. Either way, I doubt any of them would really remember the why....
For what it is worth, the times that .Net creates formats like this (e.g. the "f", "F", "g" and "G" formats among the Standard Date and Time Format Strings) it builds them by concatenating various date formats and time formats. So if there are any that display oddly for you, then you are in good company -- every version of the .Net Framework will do equally well/poorly!
# Random832 on 29 Mar 2010 6:59 AM:
What if some locale needed a "date and time" format like "dd MMM HH:mm yyyy"? Even without this, concatenating the two together _already_ loses the ability to specify which of the two comes first in the locale.
"which in English really only affects MINUTES and MONTHS" - wait - are the tokens themselves different in different languages? like "AAAA" for the four-digit year in spanish?
(looking forward to that bit on the Hebrew date format - your last mention of that and the Arabic one glossed over the difference between which part of the date/time is on the left or right vs which part comes first or last in the string - same for percentage and any interaction with the bidirectional algorithm and surrounding text/context)
# Michael S. Kaplan on 29 Mar 2010 8:01 AM:
No locale under Windows currently defines such a thing, so for the foreseeable future this is a non-issue.
Look at the documentation on the tokens - they don't both use the letter "m".....