Wierd C# DateTime Parse Error..please help

  • Thread starter Thread starter avnrao
  • Start date Start date
A

avnrao

We have a web service that gets data in xml format. In that Xml data, we
parse few date fields that are in this format

<data datefield="12/26/2008" timefield="16:33:45" ...>
we parse it into a DateTime field using DateTime.Parse( datefield ).Add(
TimeSpan.Parse( timefield ).

For some reason, on 26th of this month from 4pm to 5pm, for certain web
service calls, the date field was calculated incorrectly. Like a 12/26/2008
16:00:00 would be parsed as 12/27/2008 4:00:00. For some reason, the dates
were added by 12 hours automatically.

We have this code in production for a long..never found such an issue. It
happend only during the time mentioned above..and never before..and never
after. More
over, we have 2 servers in production, and this error happend on one of the
servers only. The other server processed the calls just fine.

We have same code deployed on both servers, and both these servers have same
configuration ( OS, patches and all ). Both these servers are identical.

Can you please tell me if you have faced such an issue before. I am not even
sure if its related to web service problem, or server problem, or database
problem.
The code was written in c#. Please let me know if you need more information.
thank you for your help..
 
Is it possible someone just changed the time on one of the servers or in
some other way the time got messed up on that server temporarily? Perhaps
someone changed the region/culture settings.

If you have a time and date format in a known format, you should really pass
in a format string for the Parse, or, at the very least, force the culture.
 
I've heard a roughly similar story. Can you determine if the caller is in a
different time zone when the call fails? There's a chance that it may be the
issue I've dealt with, basically a date deserialization issue.

--

Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The O.W.C. Black Book, 2nd Edition
Exclusively on www.lulu.com/owc $19.99
 
I've seen it happen when the timezone or culture settings are wrong.

Don't use DateTime.Parse if you know exactly what format you're expecting.
Use DateTime.ParseExact instead and pass in the format string (and an
invariant culture). Skip TimeSpan.Parse since you can't control the format
and instead combine the two strings into one before parsing. Try this:

string datetime = datefield + " " + timefield;
string format = @"MM\/dd\/yyyy HH\:mm\:ss";
IFormatProvider provider =
System.Globalization.DateTimeFormatInfo.InvariantInfo;
DateTime dt = DateTime.ParseExact(datetime, format, provider);

This assumes that single digit months and days have a leading zero. If
that's not the case try the following format string instead:
string format = @"M\/d\/yyyy HH\:mm\:ss";

/claes
 
I have just had this happen to me for a period of 2 hours, mysteriously today any date entered on a web form ended up in the database with 12 hours added. This started approx 9am 11 july 2008 and stopped 11am 11 july 2008.

No changes have been made to servers and certainly nothing was done to fix it as we were still investigating!

Dates are entered in the form "11 Jul 2008 09:30" so there is not really any room for misinterpretation!
Glad to know its not just us!
 
We had the same issue with dates added by 12 hours automatically. This happened only for few hours and then corrected by itself. Our web service is working fine so far after that. How did you resolve this issue? Any help will be greatly appreciated!
 
We had this happen recently. Here is what we discovered:

1.) It appears to be a rare glitch with the .NET language in parsing date/time strings. Our system calls DateTime.Parse() on date/time strings such as “12/10/2011 03:30”.

2.) The DateTime.Parse() method uses the current culture to understand how to parse the data. For example, our web service is set to use en-US.

3.) The .NET bug started when this web service's application pool recycled. Our application pools are routinely recycled every 6 hours to clean up memory consumed on the server due to database connection leaks. When the recycle occurred, the web service was given a corrupt culture that basically had an AMDesignator but not a PMDesignator. We have not actually proven this, but have discovered this must be the case by other research (links included below). This caused the DateTime.Parse() method to add 12 hours to every date/time that it created based on the incorrect culture it was given.

4.) The problem continued until the next scheduled recycle 6 hours later. We were able to confirm this by looking at data in our application and comparing it to the Windows Event log for when the application pool recycled.

5.) Using a test application, we were able to reproduce the situation of 12 hours being added to the date/time values. The test purposely created a blank PMDesignator and set the culture using it.

6.) We will be using ParseExact() instead of Parse(), as we know the exact format and it is not affected by the corrupt culture settings.

7.) Other URLs that we found helpful in tracking this down:
http://stackoverflow.com/questions/...-in-net-2-0-website-amdesignator-pmdesignator
http://stackoverflow.com/questions/...formatexception-on-afternoon-date-time-values
 
We checked our logs... Yes, the issue started exactly at the same time as application pool was recycled and stopped with the next recycle.
 
Using another test application, we have reproduced this error. We created a simple web service that would do date/time parsing and check various culture settings. The problem was just as we had suspected with the empty PMDesignator. We set the application pool to recycle every minute and had 5 instances of a client application hit the web service every second. After a couple of days, we finally induced the problem. The problem lasted for 1 minute - the length of time between application pool recycles. We have submitted a bug to Microsoft. We are using .NET 2.0 - I'm not sure if this is a problem in more recent versions of .NET.
 
Thanks for the update!! Why are using ParseExact method? If current culture is causing this issue all we need is to use InvariantCulture with DateTime.parse method.

CurrentDate = DateTime.Parse(current_date, CultureInfo.InvariantCulture).Add(TimeSpan.Parse(current_time, CultureInfo.InvariantCulture));
 
InvariantCulture may work - depends on what the format of the date/time string is that you are using and whether the InvariantCulture (as opposed to the en-US culture, for example) will parse it as you intended.
 
Back
Top