Posts Tagged ‘Globalizaion’

Localization and Globalization – Part 1 DateTime

December 27, 2011 Leave a comment

As the demand for applications that are “culture aware” becomes a much more frequent requirement, the implementation of it becomes more and more important. Globalization is more then just implementing the ability to change the language of the user interface, it’s many more details. It’s the way digit groupings are done, money displayed and date format to name a few.

Today I decided to dedicate this article to the various considerations that revolve around the DateTime class.

A few resources to have a look at if you’re not familiar with DateTime Class.


MSDN Library Entry for DateTime Struct

MSDN Entry for DateTime Picker Class

Code Sample

The Basics

DateTime is not a class, it is a struct. The challenge that most programmers have with this is what to initialize the struct as. For example, when initializing an int for the most part it’s initialized to 0 or –1. This is (of course) generally speaking, for DateTime I would recommend that when declared it should be initialized to DateTime.Min. DateTime.Min is equal to 00:00:00.0000000, January 1, 0001 which is a highly improbable date to ever use within a program.

The other consideration is current time. There are two methods for that DateTime.Now and DateTime.UtcNow. I would strongly recommend that UtcNow is used as often as possible. If the current DateTime is used frequently in a high speed environment (such as time stamps for packet sniffing) you must use DateTime.UtcNow. In the example program (see under resources) the differences between UtcNow and Now is below copied from the output of the program:

For 100000 iteration it took a total of 241 ms when Using DateTime.Now and 144 ms total when using DateTime.UtcNow

As you can see UtcNow is significantly faster then Now.

One last word of caution that most of the rest of the blog will be about, whenever possible (I’ve made it an unbreakable rule for me and my team) do not store dates and/or times as anything other then a DateTime (especially a string) and always verify and validate user input.


Verifying Validating Dates

The best way to make sure that the date that was entered is the right one is to restrict the user to a DateTime Picker. However, should that not be an options there’s a need to create a system of checks that both provide hints for the user on how to enter the date and once entered to verify that the date entered is the same as what the user intended. For example if the user enters 1/2/2011 did they mean January 2nd or February 1st? We’re going to take a detour and discuss localizing the date format first and then put the two topics together and create a user control that will cover both topics in one example.


Localizing DateTime Display

The screen shot below is intended to demonstrate the differenced between language (Culture Settings) and DateTime format. The screenshot is taken from the Sample that can be found here.

The first column is the description of the format. In the screen shot  I chose el-GR (Greek) as the culture. It’s important to note that if the only the format is applied it changes the date display (second column) to match what is the norm in Greece, however it doesn’t change the language (December is still shown as the month). However, on the third column where I apply the culture it changes both the date format and the language of the date.


Bringing it All Together

To bring it all together there’s a user control that provides a user a textbox to enter the date. When the control is loaded it changes the {0} in the “Enter Date” label such that it shows the format that is excepted for the current culture. Furthermore once the date is entered the the text box loses focus (meaning the user moved to the next field needing their input)the date is parsed and shown written out below the text box, that way the user can confirm it’s the right date.


Happy Codin’