Преобразовать. ToDateTime вызывает FormatException в дату/временные стоимости во второй половине дня

Решение очень простое, используйте CultureInfo.InvariantCulture . Для образцов данных это единственное разумное решение.

Я знаю, что это не объясняет разницы, но ваше программное обеспечение действительно не должно полагаться на культуру «по умолчанию» (кроме, может быть, пользовательского интерфейса).

Похоже, что объект культуры почему-то не понимает военного времени. Честно говоря, я не уверен, что делать дальше, но это может дать вам отправную точку.

Какое значение имеет свойство CultureInfo.DateTimeFormat ? Согласно MSDN :

«Пользователь может выбрать переопределение некоторые ценности, связанные с текущая культура Windows через часть региональных и языковых опций Панели управления. Например, пользователь может выбрать отображение даты в другом формате или использовать валюта, отличная от валюты по умолчанию для культура.

Если UseUserOverride истинно и 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 свойство, приложение получает значения по умолчанию для новой культуры вместо переопределений для самобытная культура. Чтобы сохранить заменяет исходный ток культура, приложение должно получить доступ DateTimeFormat и NumberFormat свойства перед изменением текущего культура. "

Может быть, какие-то пользовательские настройки преобладают над этим?

Если вы точно знаете формат, сообщите приложению, что это такое - используйте DateTime.ParseExact вместо просто DateTime.Parse . (И, как говорили другие, укажите также инвариантную культуру, чтобы убрать больше вариаций.) Это дает вам гораздо больший контроль:

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);
    }
}

Это дикая догадка, но, возможно, что-то вроде этой последовательности событий могло вызвать проблему:

1. Администратор заходит в международные настройки панели управления на всех серверах и меняет формат времени с " HH: mm: ss "to" hh: mm: ss tt ".
2. Администратор перезапускает пул приложений (или службу IIS, или машину) только на одном из серверов.

Все новые ASP.NET рабочие потоки на переработанном сервере теперь будут видеть измененный формат времени, и их методы DateTime.Parse не будут работать. Однако, если другие серверы все еще используют исходные рабочие потоки, значит, они еще не обнаружили изменений в текущем языке и региональных параметрах DateTimeFormatInfo .

Это очень маловероятный сценарий, но опять же, у вас есть очень маловероятная ситуация.

У нас есть веб-служба C # .NET 2.0, работающая на сервере Windows 2003. Эта служба работает более двух лет. Недавно мы обнаружили ошибки в этом приложении. Сообщение об ошибке: «Строка не была распознана как допустимый DateTime». Другой веб-сервер возвращает дату, и эта функция должна возвращать значение типа

«5/10/2010 12:00:00 AM»

Когда возникают ошибки, функция возвращает

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

В неверном возврате есть пробел в конце и нет AM.

Эта проблема появлялась и исчезала несколько раз в течение следующих двух недель. Изучив журналы Windows, мы заметили, что время начала и окончания ошибок совпало (в пределах одной или двух минут) повторного цикла пула приложений, который установлен (по умолчанию) на каждые 29 часов. Эта проблема возникла только на рабочем веб-сервере, а не на серверах разработки или тестирования. Мы попробовали заменить сервер, и в течение месяца ошибок не было. Теперь ошибки начались снова. Мы вручную сбросили пул, и проблема сразу исчезла. Мы бы предпочли не рассматривать это как приемлемое решение, поскольку бассейн регулярно перерабатывается.Мы не знаем, нужна ли нам переработка пула, но мы понимаем, что регулярная перезагрузка помогает повысить производительность приложения.

Веб-приложение уже использует ParseExact (), но строка формата выглядит так:

«гггг-ММ-ддЧЧ: мм: сс.0Z»

вместо

«гггг-ММ-дд ЧЧ: мм: сс »

, предложенный Джоном Скитом в этой ветке. Не знаю, будет ли это иметь большое значение.

Мы также проверили настройки культуры.

Кажется очевидным, что проблема начинается с перезапуска пула приложений, но я понятия не имею, что происходит под капотом во время этого перезапуска. В большинстве случаев повторное использование не оказывает отрицательного воздействия, и когда ошибки все же возникают, следующая повторная обработка всегда останавливает ошибки.