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 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

Cloudflare Vulnerability Does Not Affect Us

The recently reported Cloudflare vulnerability where fragments of secure, encrypted user data could be exposed to a third party does not affect Gibraltar Software even though we use Cloudflare because we only route static content through the Cloudflare proxy for acceleration. Read more

We're out of our Last Data Center

Back in January of 2016 we decided to completely transition out of our data centers and into the cloud. On Sunday we finally shut down the last cluster of our hardware. Read more for how we did it and whether we would do it all over again if we had... Read more

Rock solid centralized .NET logging

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