by Michael S. Kaplan, published on 2012/09/14 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2012/09/14/10349328.aspx
Previous blog in the series: Do you have the [short] time for this? Part #1: The intro.
With part 1, I laid out the history of long time and short time.
And I made it all sound like a story with a happy ending.
Sounds like all is good, right?
Wrong!
There are still several lingering problems.
They all have pretty much the same cause, though.
And all of them would not exist if the original Win32 solution had been used everywhere.
I'm not saying that VB, VBA, .NET, or the people clamoring for a "short time" were wrong, per se.
But I am saying that they share blame for these bugs with the NLS team members who did the work to support "short time"!
First I'll show what these formats look like in en-US, where one of the problems doesn't exist:
| LOCALE_STIMEFORMAT | LOCALE_SSHORTTIME |
| h:mm:ss tt | h:mm tt |
| hh:mm:ss tt | hh:mm tt |
| H:mm:ss | H:mm |
| HH:mm:ss | HH:mm |
You will no doubt notice that the four options for long time match the four for short time (with the TIME_NOSECONDS flag being passed for the long time!).
In other words, they can kind of do okay when they match.
HOWEVER, there is no rule that enforces a need for them to match!
And HOWEVER #2, no documentation or description suggests that such matching is needed, wanted, desired, or even pined for!
In fact, there are several examples of locales -- more then three and less than twenty -- in Windows 8 that have non-matching long time/short time formats.
But since neither the people who originally provided the data nor the people who reviewed the data in Windows 8 were ever even given an insinuation that this is the case, they can hardly be blamed for not always having done so.
I still don't know that I would want to formally request it, if no one wanted to update the documentation.
People owning the underlying technologies would have to put their money where their mouth is here, if they want to change the rules and asked for what would otherwise be gratuitous busywork.
The other problem would of course be that "fixing" those as cases would not keep people from either adding new locales or modify existing ones to make them be out of sync again.
This means that there would need to be both Locale Builder updates (all new locales and locales we reviewed were done via Local Builder), and we'd probably need some doc updates there too.
I know they aren't updating Locale Builder these days, but they will have to spend some dev cycles for an internal update if they want to change the rules to force data to be better.
Not that I would object to a public Locale Builder update, either. :-)
But no one is going to build in new requirements on top of me or us if they can't be bothered to support it in their own toolset we are relying on!
Ironically, had they never gone this "we need a unique short time" route, this problem wouldn't even exist.
Because if there was only one set of formats that were modified as needed, they would all be in sync, with no special work needed.
And if this blog seems a scosh shriller than usual, it is how often this kind of thing has been reported as a bug in the data when the real bug has actual villians who caused the problems!
And there's more -- as I'll talk about in the next part....
Doug Ewell on 14 Sep 2012 7:15 AM:
But wait, they *don't* match in your table. The entries with capital 'H' and 'HH' have 'tt' in the short format but not in the long format. Why would anyone want A.M./P.M. with their 24-hour format anyway? And in fact, on my copy of 7 the short formats with 'H' do not have 'tt'.
Michael S. Kaplan on 14 Sep 2012 10:05 AM:
Sorry, that was a bug in my table, fixed now.
referenced by