Почему CultureInfo текущего потока не используется при разборе параметра DateTime в вызове WebMethod в ASP .NET?

У меня есть приложение ASP .NET Web Forms, которое использует атрибут WebMethod для выполнения вызовов AJAX из jQuery. Я пытаюсь локализовать приложение, поэтому недавно создал веб-метод, который выглядит примерно так для целей тестирования:

[WebMethod]
public static string HandleDate(DateTime dateValue)
{
    return dateValue.ToString("f");
}

Смысл этого метода в том, чтобы убедиться, что если я правильно установлю CultureInfo, веб-метод будет правильно анализировать предоставленную дату, используя правила форматирования даты для этой культуры. К сожалению, этот код никогда не будет достигнут. Вместо этого я вижу ошибку, вызываемую вспомогательными классами, которые позволяют вызывать эти WebMethods.

У меня есть HttpModule, который устанавливает для свойств «CurrentCulture» и «CurrentUICulture» текущего потока значение «pt-BR» (бразильский португальский) в событии «BeginRequest».

На стороне клиента у меня есть вызов jQuery AJAX для этого веб-метода HandleDate, который предоставляет параметр dateValue как «18/10/2010». В языке и региональных параметрах pt-BR это должно оцениваться как 18 октября 2010 г. (формат даты день/месяц/год).

Когда я выполняю это, я получаю сообщение об ошибке, указывающее, что «System.Web.Script.Serialization.ObjectConverter» взрывается, заявляя, что «18/11/2010» не является допустимым значением для DateTime. Трассировка стека, включенная в ошибку, указывает, что это было вызвано методом System.ComponentModel.DateTimeCoverter.ConvertFrom, который принимает объект для преобразования в дополнение к объекту CultureInfo, представляющему язык и региональные параметры, которые следует применять во время преобразования.

Я запустил Reflector, и оказалось, что «ObjectConverter» вызывает «DateTimeConverter», используя экземпляр CultureInfo.InvariantCulture, что, как мне кажется, является проблемой.

Как я могу заставить эту логику использовать CultureInfo, прикрепленную к текущему потоку, вместо InvariantCulture?


person Jesse Taber    schedule 18.11.2010    source источник
comment
Я думаю, что это взрывает попытку преобразовать «18/10/2010» в DateTime, чтобы его можно было передать методу, и он не имеет ничего общего с вашим кодом dateValue.ToString("f")   -  person Greg    schedule 18.11.2010
comment
Да, код внутри метода на самом деле никогда не достигается. Это определенно взрывает анализ даты, но я хочу знать, почему. Немного уточню вопрос.   -  person Jesse Taber    schedule 18.11.2010


Ответы (1)


Я бы рекомендовал вам изменить тип параметра на string, а затем самостоятельно выполнить синтаксический анализ, используя DateTime.Parse или TryParse.

person John Saunders    schedule 18.11.2010
comment
Все сказано и сделано, это, вероятно, то, что я буду делать. Я подумал, что это несколько странное поведение для анализа дат с инвариантной культурой, и хочу знать, почему. Чем больше я думаю об этом, тем больше я думаю, что использование инвариантной культуры вполне могло быть дизайнерским решением Microsoft. - person Jesse Taber; 19.11.2010
comment
Помните, что эта инфраструктура была создана для веб-сервисов на основе SOAP. В таких сервисах существует международный стандарт для строк даты/времени, так что вопрос о том, как парсить даты, не возникает. - person John Saunders; 19.11.2010
comment
Я согласен. Я думаю, что это задумано, и это, вероятно, повлияет на то, как я предоставляю строки даты для вызовов AJAX (т. Е. Используя форматы ISO и используя «ParseExact». Принимаю этот ответ. Спасибо! - person Jesse Taber; 22.11.2010