DateTime.Parse behavior in IIS app pool

Question

Hi all,

Recently I've encountered a weird situation regarding DateTime.Parse method running in IIS app pool (.NET 2.0). My problem is I have a web service application which has run for several years and recently it started to crash, but only sometimes and on one server only out of three. The error I get is "String was not recognized as a valid DateTime.Couldn't store <2011-Aug-13 17:13:07.997> in <columnName> Column. Expected type is DateTime." when trying to merge into a DataSet having DateTime columns. All servers are the same (Win 2003 Server) (at least I couldn't find any difference in the culture settings including the NetworkService account) and run the same applications. Recycling the app pool solves the issue temporarilly, but that's not an option for production environment.

Have anyone seen such behavior so far?

The problem reduces to parsing a date time string: (String s, DateTimeFormatInfo dtfi,
DateTimeStyles styles)  so I've written a small application to test the behavior of DateTime.Parse running in IIS under different regional and culture settings:

DateTime.Parse("2011-Aug-13 17:13:07.997", DateTimeFormatInfo.CurrentInfo, DateTimeStyles.None)

The weird thing is this line works well for watever culture settings I've put on the NetworkService account or on the applictaion itself (in web.config). I've tested it with the following cultures: "en-US", "en-GB", "it-IT" and the test passes for all these cultures. It looks like the format is not taken from the CultureInfo specified as param to Parse method.

Does anyone know from where is taken the format string?

Thanks,

MM

Answer 1

The problem could be like I am using en-US culture but I might have set DateTime format in fr-FR culture (in regional settings of control panel). In that case, the datetime value will be sent to server in fr-FR format but in server your pasring the the value using en-US format (because you have detected that client culture is en-US but you do not know that client has changed the DateTimeFormat).

Just check whether this is the case.

---

Please mark this post as answer if it solved your problem. Happy Programming!

Answer 2

Just tested, but it doesn't look to be the case - i.e. I've made the call with several cultures from the client but the parsing is just working.

Answer 3

If you have a string in "2011-Aug-13 17:13:07.997" format, why dont use use DateTime.ParseExact() method, where you define the exact format, like:

"yyyy-MMM-dd hh:mm:ss:fff"

So full code would be:

string strDate = "2011-Aug-13 17:13:07.997";
DateTime date;
if (DateTime.TryParseExact(strDate, "yyyy-MMM-dd HH:mm:ss.fff", CultureInfo.InvariantCulture, System.Globalization.DateTimeStyles.None, out date))
{
    //string is recognized as a valid datetime                 
} //else, you can notify about not recognizable string

---

Mitja

Answer 4

Or you can even specify more formats (all that could be possible) in my example inside a string array:

string strDate = "2011-Aug-13 17:13:07.997";
string[] formats = { "yyyy-MMM-dd HH:mm:ss.fff", "yyyy-MMM-dd hh:mm:ss.fff" };
DateTime date;
if (DateTime.TryParseExact(strDate, formats, CultureInfo.InvariantCulture, System.Globalization.DateTimeStyles.None, out date))
{
    //string recognized as valid datetime           
}

Hope it helps,

bye

---

Mitja

Answer 5

Just tested, but it doesn't look to be the case - i.e. I've made the call with several cultures from the client but the parsing is just working.

You didn't get my point. Suppose a client UI culture is en-US. In your server, for en-US culture, DateTime format will be "MM/dd/yyyy". But, client may go to his control panel and change his DateTime format to something like "dd/MMM/yy". Now DateTime.Parse will fail in server because client was expecting DateTime input in actual en_US format "MM/dd/yyyy" but the inputis in different format (bcoz user manually changed it).

---

Please mark this post as answer if it solved your problem. Happy Programming!

Answer 6

Adavesh, is there possible to salve (predict) in which date format you will get it?

I was doing a lot of code including datetime and their string formats, but never with different types of dates at ones (in a single application) actually. Like this example here, when an application can receive dates from many different country (or cultures).

So, how to cope with this kind of problem?

---

Mitja

Answer 7

The problem what I mentioned mainly occurs when you allow the clients to send DateTime values to server in their culture format. For example, if you have a client application in India (hi-IN) and server application in United states. Server Application knows that the client is running in hi-IN culture whose DateTime format usually be in "dd-MM-yyyy hh:mm:ss tt" format. But this assumption fails when

1. User manually enters DateTime value (free tes xt)

2. User changes DateTime format in Control panel

So, if any of the above two is possible, definitely there will be problems which I mentioned above. You can overcome this problem by receving DateTime format from all clients in an universal format.

a. Never allow user to enter free text Date and Times
b. provide DateTimePicker or MonthCalendar controls for inputting the data. Or use masked TextBox to restrict the user to enter the Date & time in perticular format only

Once the DateTime object is created, get a universal datetime string from it , say "MM/dd/yyyy HH:mm:ss". Then you have one DateTime format to deal with in the server, so, problem solved.

---

Please mark this post as answer if it solved your problem. Happy Programming!

Answer 8

a. Never allow user to enter free text Date and Times
b. provide DateTimePicker or MonthCalendar controls for inputting the data. Or use masked TextBox to restrict the user to enter the Date & time in perticular format only

Once the DateTime object is created, get a universal datetime string from it , say "MM/dd/yyyy HH:mm:ss". Then you have one DateTime format to deal with in the server, so, problem solved.

for a and b: I completely agree with you. Thats why I always "force" users to pick a date, rather then write it. And using a universal date format, is surely the best idea. 

Another solution would be to define an array of all possible strings, and use it in

string formants ={"format A", "format B",...}; //like MM.dd.yyyy and so on..
if(DateTime.TryParseExact("input_date", formats,...))
{
   //rest od code if input is recognized as valid format
}

isnt it?

---

Mitja

Answer 9

Yeah..you could do that but your array size will be huge. How many combinations you will write? right?

---

Please mark this post as answer if it solved your problem. Happy Programming!

Answer 10

Yep, this is not a sensible solution. The best way then is to use universal time (a common one).

---

Mitja

Answer 11

Mitja,

You're right, but my problem is I don't make the parse call, but the the DataSet code does it, so I have no controll of that.

I've wrote that piece of code to test and try to figure out what happens and why the weird behavior.

Thanks,

MM

Answer 12

Adavesh,

I see ... tested this as well, but it works well whatever i set in controlo panel. However, this should not matter in my case as i don't use any date time control - i.e. I pass the date as a string (in query string), so the only thing which could matter was the culture the client passes to the server (which is the usual culture string fr-Fr or whatsoever).

Thanks,

MM

Answer 13

Hi mm7,

How's it going? Do you have any updates about the issue? 

---

Bob Shen [MSFT]
MSDN Community Support | Feedback to us

Answer 14

Hi,

Nothing so far. I'll come back with the resolution when i'll have one.

Thank you.

Answer 15

I have the same problem in a DNN website.

2 machines, both the same! (the one is actaully a web and datbase backup and then restored on my dev box.
One the once, somewhere a locale is not playing along, causing parse errors.
SQL language and locale teh same on both, same code, same database
Same version of SQL 2008 SR.

Please, like all the post above, I think dewvelops knows about handling differnt datetimes and parsing them or prsernting them in a different locale.

The question is what else affect the parsing. This is a DLL of dotnetnuke, that runs on lots of server, but when changing the sites locale, this one core profile module give errors.

It is exactly the same behaviour MM describes above/