Nothing like a Spelling Error on the Title Page

When I was back in College I wrote a term paper on the Challenger Disaster.  This was an issue near & dear to my heart, so I put a lot of time into the content: more than was really necessary.  I formatted the document very carefully, had two other people review my facts and figures to make sure it was absolutely defensible.  In every way I was sure I was going to knock it out of the park.

The only problem was that I miss-spelled Challenger on the title page.  It happened because I added the title page as the very last thing, and didn’t think to recheck something so simple.

Well, we just did the same thing with our latest Beta of Gibraltar - we have a simple routine in the Gibraltar Analyst designed to have it expire on the first of June so that people will come back and get the final release (even as a free demo) and we don’t have to support the pre-release versions forever.  It’s totally throwaway code, implemented in a very simple way.  We did basic testing on it, but it isn’t part of the real feature set of the software so it isn’t part of our test suite.

Lo and behold we did the date equivalent of a miss-spelling on the title page; we’re parsing the expiration date and verifying it without setting the culture, so it expires on “6/1/2009”, whatever that date happens to mean to you.  So for example in Europe that would parse as the 6th of January of this year, a date in the past.  I have no idea what bad things would happen in other parts of the world, other than it’d simply be wrong.  My sincere apologies to our non-US users for this mistake; we’ll get a fix published as soon as we can.

The original, incorrect routine:

//This is wrong - only use if you KNOW the text date is in the current culture.
DateTimeOffset parsedDate;
if (DateTimeOffset.TryParse(expirationDate, out parsedDate))
{
ExpirationDate = parsedDate;
}

And the corrected routine, always using US English for its culture:

//Here we force the culture to be what was used to write out the string date.
CultureInfo enUSCulture = new CultureInfo ("en-US");
DateTimeOffset parsedDate;
if (DateTimeOffset.TryParse(expirationDate, enUSCulture, DateTimeStyles.AdjustToUniversal, out parsedDate))
{
ExpirationDate = parsedDate;
}

If this seems painful, consider that the best way to handle dates is to not let them get into a raw string format in the first place; we use a binary serialization format throughout Gibraltar to avoid this problem.   As a final aside, if you haven’t started using DateTimeOffset as your preferred date object in .NET you should seriously consider it; We use it so we can be fully time zone aware and represent the original time zone, the current user’s time zone, and an arbitrary time zone by adjusting a single data value.

Update:  A fixed build (2.00.0357) has now been published.  We’ve replaced the incorrect previous build on the site.