Convert.ToDateTime causes FormatException on afternoon date/time values

Question

We have an application parsing date/time values in the following format:

2009-10-10 09:19:12.124
2009-10-10 12:13:14.852
2009-10-10 13:00:00
2009-10-10 15:23:32.022

One particular server all of the sudden (today) started failing to parse any times 13:00:00 or later. This particular client has five servers and only one has the problem. We have dozens of other clients with a total of hundreds of servers without the problem.

System.FormatException: String was not recognized as a valid DateTime.
at System.DateTimeParse.Parse(String s, DateTimeFormatInfo dtfi, DateTimeStyles styles)
at System.DateTime.Parse(String s, IFormatProvider provider)
at System.Convert.ToDateTime(String value, IFormatProvider provider)
at System.String.System.IConvertible.ToDateTime(IFormatProvider provider)
at System.Convert.ToDateTime(Object value)

I ran a test using DateTime.Parse(s, CultureInfo.CurrentCulture) comapred to DateTime.Parse(s, CultureInfo.InvariantCulture) and the problem only shows up with CurrentCulture. However, CurrentCulture is "en-US" just like all the other servers and there's nothing different that I can find in regional or language settings.

Has anyone seen this before? Suggestions related to what I can look into?

EDIT: Thank you for the answers so far. However, I'm looking for suggestions on what configuration to look into that could have caused this to suddenly change behavior and stop working when it's worked for years and works on hundreds of other servers. I've already changed it for the next version, but I'm looking for a configuration change to fix this in the interim for the current installation.

Answer 1

It sounds like somehow the culture object isn't understanding military time notation. I'm honestly not sure where to go from there, but it may give you a starting point.

Answer 2

If you know the format exactly, tell the application what it is - use DateTime.ParseExact instead of just DateTime.Parse. (And as others have said, specify the invariant culture as well, to take away any more variation.) That gives you much more control:

using System;
using System.Globalization;

class Test
{
    static void Main()
    {
        Parse("2009-10-10 09:19:12.124");
        Parse("2009-10-10 12:13:14.852");
        Parse("2009-10-10 13:00:00");
        Parse("2009-10-10 15:23:32.022");
    }

    static readonly string ShortFormat = "yyyy-MM-dd HH:mm:ss";
    static readonly string LongFormat = "yyyy-MM-dd HH:mm:ss.fff";

    static readonly string[] Formats = { ShortFormat, LongFormat };

    static void Parse(string text)
    {
        // Adjust styles as per requirements
        DateTime result = DateTime.ParseExact(text, Formats, 
                                              CultureInfo.InvariantCulture,
                                              DateTimeStyles.AssumeUniversal);
        Console.WriteLine(result);
    }
}

Answer 3

What's the value of the CultureInfo.DateTimeFormat property? According to MSDN:

"The user might choose to override some of the values associated with the current culture of Windows through the regional and language options portion of Control Panel. For example, the user might choose to display the date in a different format or to use a currency other than the default for the culture.

If UseUserOverride is true and the specified culture matches the current culture of Windows, the CultureInfo uses those overrides, including user settings for the properties of the DateTimeFormatInfo instance returned by the DateTimeFormat property, and the properties of the NumberFormatInfo instance returned by the NumberFormat property. If the user settings are incompatible with the culture associated with the CultureInfo, for example, if the selected calendar is not one of the OptionalCalendars, the results of the methods and the values of the properties are undefined.

The value of the DateTimeFormat property and the NumberFormat property is not calculated until your application accesses the property. If the user can change the current culture to a new culture while the application is running and then the application accesses the DateTimeFormat or NumberFormat property, the application retrieves the defaults for the new culture instead of the overrides for the original culture. To preserve the overrides for the original current culture, the application should access the DateTimeFormat and NumberFormat properties before changing the current culture."

Could it be some user setting is over-riding this?

Answer 4

It's a wild guess, but maybe something like this sequence of events might have caused the problem:

1. An administrator goes into Control Panel International settings on all servers and changes the time format from "HH:mm:ss" to "hh:mm:ss tt".
2. The administrator recycles the application pool (or the IIS service, or the machine) on only one of the servers.

All new ASP.NET worker threads on the recycled server will now see the changed time format and their DateTime.Parse methods will fail. However, if the other servers are still using the original worker threads, then they have not yet detected the changes to the current culture DateTimeFormatInfo.

It's a very unlikely scenario, but then again, you have a very unlikely situation. You could try recycling the relevant application pool on all the servers and see if anything changes.

Answer 5

Were you ever able to find a solution to this? We're seeing the same issue... and it's only on one of our few hundred servers running our application. Thanks.

Answer 6

We also encountered the same problem. Just recycle your application pool.

Answer 7

We have an C# .NET 2.0 web service running on a Windows 2003 server. That service has been running for more than two years. We recently srtarted experiencing errors in that application. The error message is "String was not recognized as a valid DateTime". Another web servie returns a date, and that function should return a value like

"5/10/2010 12:00:00 AM"

When the errors are occurring the function returns

"5/10/2010 12:00:00 "

The incorrect return has white space at the end and no AM.

This problem appeared and disappeared several times over the next couple of weeks. After examining the windows logs, we noticed that the start and end times of the errors coincided (within a minute or two) of an application pool recycle that is set (by default) to occur every 29 hours. This problem only occurred on the production web server, and not on the development or test servers. We tried replacing the server, and there were no errors for a month. Now the errors have started again. We manually reset the pool and the problem disappeared immediately. We would rather not view this as an acceptable solution, as the pool recycles regularly. We don't know if we need the pool recycle, but it is our understanding that regular recycles help with application performance.

The web application uses ParseExact() already, but the format string looks like this:

"yyyy-MM-ddHH:mm:ss.0Z"

instead of

"yyyy-MM-dd HH:mm:ss"

suggested by Jon Skeet in this thread. I don't know if this would make much difference.

We also checked the culture settings.

It seems clear that the problem begins with the application pool recycle, but I have no idea what occurs under the hood during that recycle. Most of the time the recycle has no negative effect, and when the errors do occur, the next recycle has always stopped the errors.

Answer 8

Hey Brian, Did you ever find the solution to this problem? Thanks Dan

Answer 9

@Brian Begley Thanks for the reply. We were recyling a app pool every hour due to a leaky program. The problem seemed to only occur on Monday's when our site demands are their highest. I'm in the process of finding the memory leaks in the code but it sounds like that is not the entire solution if you recycle once each week. I logged the memory usage of this app pool during the last crash and it was not high at the time of the crash. This is truely a mysterious problem. I wonder if we have similar settings or apps. For example, do you have an app pool monitor running?