by Michael S. Kaplan, published on 2007/09/01 21:06 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/09/01/4696229.aspx
(I will explain the title at the end of this post if you aren't sure yet what it means!)
In Vista, a new function was added to display duration -- GetDurationFormat (and of course the name-based version, GetDurationFormatEx, for all of the people who have noticed that LCIDs kind of suck).
Both functions have some interesting characteristics. For example, both of them only support Unicode. Neither has an "ANSI" version. Like I have been saying, this is the future ad in my opinion it is about time. :-)
Another interesting fact is that they support not only the hour/minute/second values one would expect but they also can move up into days and down into fractional seconds (in fact as far down as being accurate to within 100 nanoseconds!).
The preceding two points are cool as hell and I am really glad that they are true.
There is also a third fact, one that is slightly less impressive....
And that fact?
Well, it turns out that only a few of the locales actually include a format string option that includes DAYS or FRACTIONAL SECONDS:
And then there is one that looks potentially broken with invalid tags that I guess are just going to be treated as literals:
Maybe that is expected -- any Assamese folks wish to comment on this? :-)
You can retrieve the data by calling either GetLocaleInfo or GetLocaleInfoEx with the LOCALE_SDURATION lctype value, at which point you will notice an additional problem -- you can't actually find any of the above strings -- the first string in a list of them per locale is the only one ever used or returned, and with the exception one of the maybe odd-looking Assamese strings, none of them is the first string in the list, so you can't ever get at this data....
Obviously a bug to fix (perhaps a new enumeration function to get them all back since several locales include more than one, or else some new lctype that will return all of the available formats in some delimited format....
But for now, if something is not lasting very long or is lasting for a very long time, or if you need better precision, you are kind of on your own finding the culturally appropriate format string to use.
Please feel free to use what is given above until an unless something better comes along, though be warned that since this data has never been exposed anywhere, it has likely never been seen in use anywhere and thus not subject ti the kind of scrutiny that quality data often requires. :-)
For the title, I don't know the planned ship date of the next version of Windows or even the next service pack, but I am sure of one thing -- it would not be convenient to count that time in hours, minutes, and seconds. So clearly the current support in GetDurationFormat/GetDurationFormatEx will not be able to give you a nicely formatted string estimating the time for a fix. You'll have to supply your own....
This post brought to you by