3

I have several forms within my MVC app that have date values which are chosen via a datepicker tool. This works well when debugging locally but on deployment to the cloud environment my dates are not being correctly converted. I have the following code:

string[] uploaddate = form.GetValues("uploaddate");
string[] expirydate = form.GetValues("expirydate");

This gets the date as 31/08/2013 etc. and from here I was converting to DateTime as follows:

Convert.ToDateTime(uploaddate[0]);
Convert.ToDateTime(expirydate[0]);

When I deploy to the Azure server I receive the following error:

String was not recognized as a valid DateTime.

I think that the instance image has a culture of US while my application was designed in UK format. How can I get around this problem so that the information is saved to the database regardless of the culture of the user?

doitlikejustin
  • 6,293
  • 2
  • 40
  • 68
Jay
  • 3,012
  • 14
  • 48
  • 99

3 Answers3

4

you should use DateTime.TryParseExact. You can specify all the possible formats and it won't throw exception either.

Example from MSDN.

string[] formats= {"M/d/yyyy h:mm:ss tt", "M/d/yyyy h:mm tt", 
                   "MM/dd/yyyy hh:mm:ss", "M/d/yyyy h:mm:ss", 
                   "M/d/yyyy hh:mm tt", "M/d/yyyy hh tt", 
                   "M/d/yyyy h:mm", "M/d/yyyy h:mm", 
                   "MM/dd/yyyy hh:mm", "M/dd/yyyy hh:mm"};
string[] dateStrings = {"5/1/2009 6:32 PM", "05/01/2009 6:32:05 PM", 
                        "5/1/2009 6:32:00", "05/01/2009 06:32", 
                        "05/01/2009 06:32:00 PM", "05/01/2009 06:32:00"}; 
DateTime dateValue;

foreach (string dateString in dateStrings)
{
   if (DateTime.TryParseExact(dateString, formats, 
                              new CultureInfo("en-US"), 
                              DateTimeStyles.None, 
                              out dateValue))
      Console.WriteLine("Converted '{0}' to {1}.", dateString, dateValue);
   else
      Console.WriteLine("Unable to convert '{0}' to a date.", dateString);
}
Ehsan
  • 31,833
  • 6
  • 56
  • 65
  • 1
    The hazard in this approach is that dates such as 8/5/2013 (August 5, 2013 to me in the US) can be ambiguous. Such a date could be mis-parsed as May 8th, 2013 on its way "across the pond", and nobody would be the wiser. – Eric Lloyd Aug 28 '13 at 17:57
3

I'd improve the date picker so that the value it posts back is always yyyy-MM-dd but displays in whichever culture you care about. This makes the problem a client problem, not a server one (which it is really)

UPDATE

I've done some investigation Convert.ToDateTime() simply calls DateTime.Parse with the current culture settings. I've just checked one of my VMs and it runs with US local settings which is why your're getting the error you are with d/M/y. I would standarise the format of the date that is being sent to the server (it doesn't really matter to which format, but I'm always a fan of YMD) and then use DateTime.TryParseExact() that @No One mentions, but with just one format.

knightpfhor
  • 9,299
  • 3
  • 29
  • 42
  • I think this is the solution I will try, why does posting in yyyy-MM-dd make it any easier to convert? And how could I go about using the culture? – Jay Aug 28 '13 at 19:21
  • yyyy-MM-dd is a sub-part of the ISO 8601 date format, which eliminates ambiguity. Essentially a pattern of nnnn-nn-nn will always be parsed as yyyy-MM-dd. – Mark Rendle Aug 28 '13 at 19:36
  • Does it go yyyy-MM-dd HH:mm:ss? I am uploading it to azure database through a windows azure cloudapp but no matter how i put the date format it doesnt seem to be working i am getting an invalid DateString format error – Jay Aug 28 '13 at 20:25
0

You can use the overload of Convert.ToDateTime which allows you to specify a culture. This will allow you to force it to always use UK culture if that is your requirements.

Reed Copsey
  • 554,122
  • 78
  • 1,158
  • 1,373