ASP.NET, ObjectDataSource and DateTime Culture Problems

If you want to display and especially provide editing capabilities for DateTime data in ASP.NET applications, you’ll surely sooner or later run into problems.

Without any exact format specifiers, your DateTime data may display in a wrong format, but this can be corrected by providing your desired format string to the binding expression.

However, when you edit a DateTime value e.g. in a TextBox, you’ll soon start getting “Could Not Convert” exceptions. It turns out that, initially, ObjectDataSource uses the default Culture of the current thread to convert DateTimes to and from strings, and that Culture is the Culture of the server, not the user agent.

There are some commonly seen solutions to this that recommend forcing conversions in the right format in your data control’s Updating event handler.

A cleaner solution that also removes the need to specify explicit format strings is to adopt the user’s Culture as the server Thread’s Culture and UICulture. Here’s how:

1. Add a Global class to your Web Client project by going to Add New Item and selecting Global Application Class. Global.asax will be created with its code-behind class Global.asax.cs.
2. Add the following namespaces to use in the class: System.Globalization and System.Threading.
3. Add the following to the Application_BeginRequest handler:

   string lang = Request.UserLanguages != null ? (Request.UserLanguages[0] ?? string.Empty) : string.Empty;
   CultureInfo info = CultureInfo.CreateSpecificCulture(lang);
   Thread.CurrentThread.CurrentCulture = info;
   Thread.CurrentThread.CurrentUICulture = info;
   

2008-01-11 Fixed a possibility for ArgumentNullException in CreateSpecificCulture.

About the Check Mark as a Bullet in Finnish Text

Localization is not only about translating, among other matters, it is also about taking care that various symbols carry their intended meaning in a cultural context. Certain symbols are bound by directionality: a person used to reading right-to-left text may misunderstand such a symbol quite badly. In some cultures, certain colors have a meaning rather different from the Western viewpoint. Also, in case of the actual symbol shape, divergence may occur.

One example of a seemingly safe but in one case quite bad choice of a symbol is the check mark (✓, CHECK MARK, Unicode U+2713) as a bullet. It is used throughout various texts and presentations, especially in those that originate in the United States.

The meaning that one may associate with this symbol may be correct or bullet point. However, in Finland this symbol has been used for exactly the opposite; for example, teachers use it to mark incorrect answers. The symbol to use as an indicator of a correct answer in Finland resembles a percent sign, but with dots instead of circles. This symbol is also available in Unicode (but in very few fonts), though with a different name (⁒, COMMERCIAL MINUS SIGN, U+2052).

Below is a screenshot from the Mozilla Europe Firefox 2 page. Here the check mark is obviously used as a list bullet. But there is a risk of misunderstanding or at least of mixed signals — and the red color won’t help either, as tests and such are usually corrected with red markings!

What to use as a bullet in a Finnish context, then? The most recommended symbols, especially in official texts, are the en dash and the asterisk. One might want to use a more decorative asterisk such as ✱ U+2731 HEAVY ASTERISK or ✻ U+273B TEARDROP-SPOKED ASTERISK as oppsed to the regular asterisk in a font. Dot, square and triangular bullets (e.g. • U+2022 BULLET, ‣ U+2023 TRIANGULAR BULLET and ▪ U+25AA BLACK SMALL SQUARE) are often acceptable as well.

How about the case in the screenshot above? I don’t know. It’s up to the graphical designers. Just don’t use a check mark.