Today I was merging the Subtext 1.9 branch back into the trunk in our SVN repository and I came across an interesting "Gottcha" to keep in your back pocket - Microsoft has changed the Time Zone settings with the fix for KB928388.

The Back Story

One of the great things that Subtext has going for it (from a developer's perspective) is our great suite of Unit tests. At the time of this writing we were up around 39% code coverage. So, being the contentious developer that I am, after I merged the branch into trunk and cleaned up any conflicts, I ran our Unit Test suite.

My initial run of the tests resulted in over 130 failed tests... WTF? I quickly realized that I had forgot to upgrade my database to work with the latest code - so I ran the upgrade scripts and stored procedure script and I was back in business. On the next run I still had over 100 failing tests. Time to start debugging.

Failing TimeZone tests?

This particular TestFixture was aimed at testing

a specialization of the abstract TimeZone class that implements time zones based in the time zone information found in Windows.

Phil wrote this specialized abstraction for some very cool TimeZone work that he did a while ago... and then added it to Subtext! If you want to see more, take a look at the Subtext.Framework.Util.WindowsTimeZone class.

At any rate, the first test that I took a look at was the TimeZoneTest.CanGetById test. This test uses MbUnit's RowTest Attribute which allows you to pass in a series of test criteria and expected values. For this test we were trying to make sure that we could find the correct WindowsTimeZone object when searching for it by it's Id. To make sure we found the correct one, we were testing several of it's Properties against our passed in Expected Values.

One of the Expected Values we were testing was the DisplayName. For this test, we were testing with the Pacific Standard Time Zone - for which we were expecting a Display Name of (GMT-08:00) Pacific Time (US & Canada); Tijuana. We expected wrong!

The fix broke us

At first I didn't understand why this test was busted... it was working just fine on our CI server, but was utterly broken on my machine. Looking in SVN, I had made no changes to the WindowsTimeZone class, nor the test fixture. I was about to start pounding my head against the wall when all of the sudden then I remembered something... a Windows Update fix that I had applied to my machine earlier that week.

I didn't remember the exact fix number, but for some reason I had read the description prior to installing it and knew that it had something to do with the new time zone laws that go into effect for the U.S. in Spring 2007. I logged into the build server, and went to the Windows Update site... and there it was. The fix for KB928388.

If you take a look about half way down the page you'll see a section called "DTS and time zone settings." That's the area that we're interested in. Look for the row with a Registry subkey name of Pacific Standard Time, 5th from the bottom.

Now, if you look at the Display Name column you'll see the problem. With this fix the Display Name for that time zone has changed. Basically they just dropped the Tijuana off the end - but that is more than enough to make our unit test fail!

A Quick Fix

I adjusted the unit test to look for the new DisplayName and like magic, that test went GREEN! My next step was to install the fix on the CI Server so that it wouldn't choke on the modified unit test.

I'd advise everyone to go ahead and install this fix as you'll need it this Spring anyhow... and if you put it on your machine now you might just find a few quirks like this one!

Happy Testing!