Geeks With Blogs
On the Ledge The general evolution (and occasional regression) of a .NET developer

The first bug I was asked to fix, here, was a bug in the Q Framework.

Our websites use a little pop-up, calendar datepicker (I believe it's the jQuery datepicker, but I'd have to check).  The problem we were experiencing is when we added a UK client.  As most of you know, the UK displays dates in DD-MM-YYYY format as opposed to the US MM-DD-YYYY format.

This trivial detail actually has a wide range of implications.  First of all, any US-oriented datepicker is going to have a conniption if you pass it a date like 24-06-2007.  In our case, it rendered the control inoperable.  The page worked fine - you just couldn't change the date.

The other side of the problem was on the data side.  It's one thing for 24-06-2007 to throw an error; it's a completely different thing for 06-07-2007 to select data from June 7 when what you really wanted was July 6, especially in a report.

In our application, we get the country of the organization the login belongs to - so our app knows our UK client is in the UK.  The hack solution for this is to find our code that deals with date formatting on our pages and reports (which is mostly in one spot - a few rogues out there) and slide in an if statement.  If this is our UK client, use this format, otherwise leave it in US format.  That solution does fix the problem in a very fast timeframe, and the code is so simple that even junior-level developers can understand and modify it.

The problem is that I'm setting myself up for a death spiral.  As we move into other countries and cultures, I'm going to be adding more and more conditions and more and more hard-coded formats to that logic.  That's assuming we even remember to do it when we add a new client from a new country.

The first thing was to check and make sure that the thread's Culture property was being set.  When the user logs in, we should be finding their country/culture information from persistence (it's the database in this case) and setting the thread's Culture to it.  Something along the lines of:

Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture(organization.Culture);

So, it doesn't matter where you're logging in from, what our culture is, or what yours is, we set the thread's culture to match yours.  This should take care of many default formatting issues, including dates.

This was already being done, so after poking around, I found our reporting datepickers and fields were using a date format hard-coded to DD-MM-YYYY.  It's easy enough to change this.

pickedDate.ToString("d", Thread.CurrentThread.CurrentCulture)

Maybe not the most impressive coding in the world, but I was the first developer to make a change to the Q Framework other than the author, and that's pretty cool.  Also, this little bug fix turned out to be little because the existing codebase took the Single Responsibility Principle quite seriously.

Ok, I actually did have to change code in two places and not one place, so Plato's ideal might not have been hit yet, but still.  Coding a fix in two places that fixes about 20 other applications is still pretty nice.

Posted on Monday, September 21, 2009 1:16 PM Architecture , How-To | Back to top


Comments on this post: Culture Club

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © ledge | Powered by: GeeksWithBlogs.net