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 than 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.
Given below are a few resources to have a look at if you’re not familiar with DateTime class.
Resources
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 than 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 option, 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 differences 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 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 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.
CodeProject
Happy coding.
This member has not yet provided a Biography. Assume it's interesting and varied, and probably something to do with programming.
Submit an article or tip
