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.

Related Posts

Loupe Agent for .NET Core Now Available

The first release of the Loupe Agent for .NET Core is also our first open source version of the Loupe Agent. This is the first step in our plan to open source the entire Loupe Agent to make it easier for anyone to extend and take advantage of what Loupe... Read more

We've Moved Loupe Service to App.OnLoupe.Com

Loupe Service now has a shorter, direct site name that's faster, anywhere in the world. Just to go App.OnLoupe.Com, the new CDN-accelerated endpoint for the Loupe Service. Your existing Agents and Loupe Desktops are unaffected by this change, but access to the web UI will be redirected to the new... Read more

Loupe 4.5 Released with New Log Viewer for Web

Rapidly diagnose each error in any .NET application with our new Web Log Viewer and Exception root cause analysis, new in Loupe 4.5. New integration with Azure Service Bus and Azure Search enables full Loupe functionality without any Virtual Servers in Azure. Read more

Rock solid centralized .NET logging

Unlimited applications, unlimited errors, scalable from solo startup to enterprise.