Customizing date formats in ASP.Net

I have known Paul Litwin for a while, now that I think about it. He and I have spoken at the same conferences, been involved with the same book projects, and so on a bunch of times in the past, and there was even a period back during the Access 95 beta of a week or so that we both "figured out" Jet replication together despite not having met at that point, by a semi-continuous stream of phone calls and emails (he was writing the replication chapter for the Access 95 Developer's Handbook, I was just really interested in Jet replication and had no life; we were both a very motivated pair of geeks!).

Anyway, Paul sent me the following question in mail the other day:

Hey there. I have a question about dates and globalization.

I have an asp.net 1.1 app that is used in the USA only. However, they want dates to be handled as dd-MMM-yy. Do you know of an easy way to alter the treatment of dates both in textboxes and in the display of them in datagrids, etc?

Thanks,

It's actually an interesting question, one that does not have a single, easy answer. Some time ago the decision was made that ASP.Net wouldn't generally want to be depending on Regional and Language Options on a random hosting server, plus the performance of a useUserOverride==false CultureInfo object is always going to be better than one that has to be checking what the user overrides might be.

The upside of all this is that in .NET 1.0 and 1.1 there is no easy way to set a particular override and make it stick everywhere, since there is always going to be a new thread that creates a new CultureInfo, and there was no way to get a DateTimeFormatInfo.ShortDatePattern with that overridden date format of dd-MMM-yy to be automatically in the CultureInfo of every new thread....

The easiest thing to do here while staying in the System.Globalization namespace is to create a DateTimeFormatInfo, set it's ShortDatePattern appropriately, and then use it as an IFormatProvider in each date formatting operation, while the easiest thing to do overall is to simply hardcode the date format in all of the various places -- basically to not be using the current culture mechanism to be setting up the formatting at all. Though either way is certainly a bit of extra work that keeps one from being able to use a lot of the built-in support.

This is a situation that gets much easier with .NET 2.0, using a CultureAndRegionInfoBuilder or the Locale Builder to create a supplemental custom culture with the specific ShortDatePattern. Just getting that custom culture on the server and setting its name as the culture for the application is all you have to do -- you let ASP.Net do all of the setting of the culture automatically for you....

One bit of trivia -- the original design of custom cultures (once replacement cultures were added) did not allow you to actually use replacement cultures when useUserOverride was set to false since it seemed like custom cultures were the ultimate form of overrides, but this design principle was abandoned when it was discovered that ASP.Net was never setting this attribute to true (for the reasons mentioned earlier). We simply didn't want to make the new feature less available to ASP.Net.

Even more trivia -- in the original design, for performance reasons, we made the decision to always look first to built-in cultures when useUserOverride was false and first to custom cultures when it was true. Although truth be told this pattern was also abandoned before .NET 2.0 was released as we decided the creation semantic was just a bit too complicated for people to easily discern how things were being created and why. It was just too good of an example of why it is better to be smart than clever....

This post brought to you by d (U+0064, a.k.a. LATIN SMALL LETTER D)