by Michael S. Kaplan, published on 2008/10/19 12:59 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/10/19/9006393.aspx
The question was deceptively simple:
Hi,
How can convert a DateTime to culture specific ShortDateTime string format without minutes?
e.g: To represent 6 PM in different cultures:
en-US --> 6 PM
de-DE--> 18
Regards
Regular readers will know why I suggest the question as being deceptively simple.
After all, they probably remember blogs from the past like Customizing the SHORT time format?, We do seem to be short on time...., and Predictably (in retrospect), aka Where Wild^H^H^Hindows-Only Things Are, aka SHORT [on ]TIME for a LONG TIME, which talk about a slightly different but nevertheless somewhat related problem.
So they know that there are some potential issues here.
In the native, Win32 world, there is GetTimeFormat and GetTimeFormatEx, which has specific flags that developers can use to modify the locale-specific format:
| TIME_NOMINUTESORSECONDS | Do not use minutes or seconds. |
| TIME_NOSECONDS | Do not use seconds. |
| TIME_NOTIMEMARKER | Do not use a time marker. |
| TIME_FORCE24HOURFORMAT | Always use a 24-hour time format. |
Obviously what the question is asking for is that TIME_NOMINUTESORSECONDS behavior.
Well, it is for that behavior, in managed code.
But managed code works purely on the "format strings" model without specific flags to methods to modify the behavior.
So the only solution here is to parse the format string using the same rules that GetTimeFormat and GetTimeFormatEx use:
If TIME_NOMINUTESORSECONDS or TIME_NOSECONDS is specified, the function removes the separators preceding the minutes and/or seconds members.
If TIME_NOTIMEMARKER is specified, the function removes the separators preceding and following the time marker.
If TIME_FORCE24HOURFORMAT is specified, the function displays any existing time marker, unless the TIME_NOTIMEMARKER flag is also set.
Obviously this should be done with some care to avoid screwing the string up, which is an occupational hazard of string parsing/modification in such cases....
The bigger issue is whether such functionality should be built in.
Now one could argue that additional format strings should be added, as well as additional string "types" to allow the developer to choose which string to use based on their scenarios -- somewhat like choosing between long time and short time.
But this is a lot of extra data to include with no good reason to add it other than a belief that in specific locales the behavior of the native-style flags would return unexpected results. Using that criteria, even the short time format wasn't really needed (and frankly would probably not have been included if it did not already exist in Visual Basic), so in the long run it would probably be better to see something analogous to the flags added to managed code.
Will they do it? Who knows, really?
But it would make sense from the standpoint of what developers might want....
This blog brought to you by ʉ (U+0289, aka LATIN SMALL LETTER U BAR)
# John Cowan on 21 Oct 2008 12:26 PM:
(Insert gripe here about over-localized functions in certain environments, to remain nameless, that refuse to provide the current date without localizing it, and thus making it unreasonably difficult to determine the numerical date therefrom, without lots of stoopit tables of month name to month number equivalences for all the many, many possible locales.)
referenced by