Say you've a black-box application that you can't change that is culture-ignorant and returns a date as a string that looks like this:
6/11/2003 1:56:31 PM
but your client wants it output like this
11-Jun-03 01:56:31 PM
Sometimes folks ask me "What's the best way to parse a Date string in .NET?" Often they are old school VBA-type folk and they are really saying "I'm going to use InStr() to parse this date unless you stop me."
So, here's a better way, IMHO. I believe in avoiding Mid$, InStr, strstr, etc...it's just not my business to parse strings. This is, of course, not the only way, but a possible way. (Certainly the CultureInfo should be cached, things could be better localized, etc):
System.IFormatProvider format =
new System.Globalization.CultureInfo("en-US", true);
DateTime lastLogin = DateTime.Parse(Session["lastSignOn"].ToString(),format);
lblLastLogin.Text = String.Format("Your last login was: {0}", lastLogin.ToString("dd-MMM-yy hh:mm:ss tt"));
Note that we know we are getting a the string as a U.S. formatted date time, we pass in our CultureInfo object that implements IFormatProvider to DateTime.Parse, then pass it our custom Format String to the new DateTime object's ToString().
This is the kind of higher level layer of abstraction that allows me to focus on business and avoid work. Parsing DateTimes is administrivia...it's lame-o work. The Marketects at Microsoft say "Do more with less" but I prefer my own saying "Do more business, do less work."
Put it down sir...step away from the manual string parsing code...no need for strstr() here...