Do you have the [short] time for this? Part 3: What a tangled we weave...

by Michael S. Kaplan, published on 2012/09/17 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2012/09/17/10350018.aspx

Previous blog in the series:

• Do you have the [short] time for this? Part #1: The intro.
• Do you have the [short] time for this? Part #2: How does it feel to be out of sync?

 I could end it right here, really.

I've already proven that as designed it doesn't work so well.

I've proven that:

1. some of the current data might be considered broken by a reasonable person, and
2. the tool used to create new locales doesn't enforce creation of proper data, and
3. the same tool, when used to review/modify existing locales doesn't help the problem then either, and
4. the DateTimeFormatInfo class, whether used normally or to publish a new custom culture, doesn't help either. 

So really, I could stop right there.

But inside me are many facets.

There is the engineer, who doesn't like when code isn't done right.

And there is the architect, who doesn't like when things aren't designed the right way.

And there is also the lawyer, who after having proven his point, can't stop himself from proving it more!

So let's take a look at that dialog in Regional and Language Options, the one that has both long time and short time:

let's look at one of those dropdowns.

And change the format:

Now once you make that change to the long time format, to put in on 24-hour time.

Look at the clock in the notification area:

Huh?

So we changed the long time and not the short time, and what is arguably the most visible short time in Windows since Windows 95 changes.

The next thing to try is just change the short time, and leave the long time alone:

Okay, let's apply that change.

The one that the examples clearly show.

And let's check out that clock again:

What the hell?

Okay, it looks like people who use GetTimeFormat with the dwFlags value of TIME_NOSECONDS | TIME_NOTIMEMARKER are not using the short time value.

Don't worry, they fixed this problem in Windows 8.

I guess they felt kind of silly :-)

Of course, it looks like upgrade doesn't migrate the setting to the other setting, but that's another story.

Didn't this change fundamentally change the definitions of where the settings are used? That just seems like a backcompat nightmare.

But let's think about this UI for a moment.

Any time you change one, wouldn't you find it reasonable if the applet changed the other for you?

The number of times that you'd want them to be different? I'm guessing that's pretty rare.

The default behavior should be to not have them different!

Anyhow....

Wouldn't it have been easier to not go the dedicated short time route?

I mean, rather than fixing all these inconsistencies in the data.

And in Regional Options.

And in .NET.

And in custom cultures.

And in the Locale Builder?

That's a minimum of four teams at Microsoft, located on two different continents.

What a tangled we weave....

Doug Ewell on 17 Sep 2012 7:17 AM:

go to newer or older post, or back to index or month or day