Deploy c# application but on beta testing crashes because of date format

Question

I am wondering if anyone has experience in deploying an application worldwide and how they handled date formats in their application?

For example, I am UK based and the date format is DD/MM/YYYY but my application crashes for customers in the US because the date format is MM/DD/YYYY .

The date get saved as text into a config file and is recalled and used in the app. However, UK, European and Australian customers dont have any issues, but US and Canada customers do.

I assumed .Net would handle the date and I use DateTime.Parse(strDateFromFile) and it crashes. ie "12/31/2010" failed but "31/12/2010" was ok.

Is there something in .Net that I can do to ensure local dateformat is correctly parsed.

I have tried converting the string to a known format and back again but seems to be a problem also:

     static public string DateToString(DateTime dtDate)
    {
        string strDay = dtDate.Day.ToString();
        string strMonth = String.Format("{0:MMMM}", dtDate).ToString();
        string strYear = dtDate.Year.ToString();
        string strDate = string.Format("{0}-{1}-{2}", strDay, strMonth, strYear);

        return strDate;
    }

    static public DateTime StringToDate(string strDate)
    {
        DateTime dtDate = new DateTime();

        try
        {
            dtDate = DateTime.Parse(strDate);
        }
        catch (Exception ex)
        {
            Logger.Log.Error(MethodBase.GetCurrentMethod().ToString(), ex);
            System.Windows.Forms.MessageBox.Show(string.Format("DEBUG INFO:  Date Format: {0}\r\n{1}", strDate, ex.Message));
        }
    }

Any advice on how I should handle the date in my application would be gratefully accepted as I use the date throughout the application.

Thanks

Answer 1

You need to pass in the current culture when you do a DateTime.Parse:

DateTime dt = DateTime.Parse("1/1/2000", Thread.CurrentThread.CurrentUICulture);

As for setting the culture for the current thread, I'm not sure if that happens automatically based off of the user's settings or if it defaults to the culture used during development.

Also note that you will need use this same trick for ToString calls for numbers and DateTimes (and possibly others too). If it becomes a big problem, you might consider getting ReSharper, which has a warning for using culture-specific ToStrings.

Answer 2

If you're accepting user input, you're not going to try to set culture info, you merely need to know what to expect when they enter something. In other words, you need to know what their culture info is, and handle it accordingly.

The System.Globalization namespace provides pretty much what you need to accomplish this. For example, if my app does this when running on my own machine (I'm in the USA):

DateTimeFormatInfo dtfi = CultureInfo.CurrentCulture.DateTimeFormat;
string dateTimeFormatPattern = dtfi.FullDateTimePattern;

I get this string:

dddd, MMMM dd, yyyy h:mm:ss tt

Or use the ShortDatePattern:

CultureInfo.CurrentCulture.ShortDatePattern = M/d/yyyy

You can use this information to know what to expect from the user, and parse it accordingly.

Check this question/answer out:

http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread/cb19f31c-6d30-4cd9-8644-80ce3ecde52f/

But I think that @Eric_Andres's answer may be closer to what you're looking for...

Answer 3

I've had settings files that are used in different countries (Canada, US), but then they are retrieved to my system (I'm in AU) for figuring out something. Things start to get very odd when you look at (1/10/2011) is that October 1 or 10 January. It depends on where it originated so I moved away from Human readable dates in my settings files. Instead I used DateTime.Now.ToBinary and store the long that way it doesn't matter where I load it, it will always come out correctly.

For Logging I always picked a format that I was happy with and used that in my Formatting.

yyyyMMdd HH:mm:ss.ffff this way you aren't at the mercy of any regional settings etc. The logging really is for you to be able to track down an issue so I don't really care if the customer is trying read it.

If you are also coordinating other systems with the remote ones, consider recording your information using UTC instead of the local time.

Answer 4

If you need your config or log or whatever files sent around, then choose ONE date format and create manual parser for it. Split the string , read numbers by Substring() , int.Parse() them...