"Always-fresh" releases of dasBlog are available from http://www.paulvanbrenk.com/blog/bits. These builds are made from the subversion head hourly, so these may not be the most stable, but are the most recent.

It seems VS 2003 has been out forever, but sp1 has been released for download yesterday. I never experieced any real problems with it, but it's great to see the DDCPX team is still working on improving its stability.

Although there are several ways in ASP.Net to influence the way DateTimes are displayed some methods are better than others and some are evil.

The easiest way to display DateTime and have some influence on them, is to specify the culture and the uiCulture in the globalization tag in the web.config. This is the preferred way if you can use the default date/time formats in that culture.

Example:

is rendered as "16-8-2006 10:14:49" with this globalization tag and rendered as "8/16/2006 10:18:37" with the culture and uiCulture set to en-US.

If you want a little more control, or when the default date/time formats don't offer enough flexibility you can specify a format in the ToString method of the DateTime object. This will still use the culture specified in the web.config for the (abbreviated) names of the months. The downside to this method is that you have to remember to set the correct format string, every time you want to display a date/time.

Example:

is rendered as "16 août '06" with the culture set to fr-FR ( the \\ are required for escaping the ' ).

When you want to offer your users a localized version of your web-application, you can't rely on the globalization settings in the web.config, instead you'll have to either set the Culture and UICulture of the current executing thread or use one of the ToString overrides that accepts an IFormatProvider. When you only specify an IFormatProvider, the default (or G) format is used to render the string and although you can override the default format, that is generally considered evil.

Example:

is rendered as "16/08/2006 11:43:11", while is rendered as "16 ago '06".

These methods were the only methods that were available on version 1.x of the .Net framework. In .Net 2.0 you have the ability to define a custom culture using the CultureAndRegionInfoBuilder class. After creating a new culture, this new culture can be installed on a computer and used by any application on that computer. This allows all (web-)applications on that computer to use the same formatting for dates, and numbers, casing etc. This way you can change the default format for string rendering in a less evil way.

Example:

First setup the custom culture using a console application, since this requires administrator rights.

They have been around for a bit, hiding as delegates, but they're getting some much deserved attention from Joel [0] and Raymond [1].

Joel is critical about the implementation in C#; while Raymond Chen is starting a series about their implementation and subtle errors. I'm not sure I can totally agree with Joel, since I like the obviousness (and typesafe-ness) of defining delegates and calling them as methods, while the compiler handles the plumbing.