FileHelpers будет анализировать дату и время только в том случае, если строка даты соответствует универсальному формату времени - PullRequest
Новая
       45

FileHelpers будет анализировать дату и время только в том случае, если строка даты соответствует универсальному формату времени

0 голосов
/ 18 октября 2019

Мое поле даты и времени будет анализироваться только в том случае, если для форматера установлен универсальный формат времени, а время даты уже в этом формате. Это ожидаемое поведение, или оно должно быть в состоянии взять любую правильную строку даты и отформатировать ее в другой формат? Если так, как это разрешается?

Это работает, если ввод даты уже в универсальном формате: 

[FieldTrim(TrimMode.Both)]
[FieldConverter(ConverterKind.Date, "yyyy-MM-dd hh:mm")]
public DateTime Transaction_date; //where Transaction_date CSV value = "2019-01-02 6:00"

Это не работает: 

[FieldTrim(TrimMode.Both)]
[FieldConverter(ConverterKind.Date, "yyyy-MM-dd hh:mm")]
public DateTime Transaction_date; //where Transaction_date = "01-02-2019 6:00"

Это исключение для приведенного выше кода:

"Сообщение": "Произошла ошибка.", "ExceptionMessage": "Ошибка преобразования '01 -02-2009 06:00 'в тип: 'DateTime'. Использование формата: 'гггг-мм-дд чч: мм' "," ExceptionType ":" FileHelpers.ConvertException "," StackTrace ":" в FileHelpers.ConvertHelpers.DateTimeConverter.StringToField (String from) \ r\ n в FileHelpers.FieldBase.AssignFromString (ExtractedInfo fieldString, строка LineInfo) \ r \ n в FileHelpers.FieldBase.ExtractFieldValue (строка LineInfo) \ r \ n в FileHelpers.RecordOperations.StringToRecord (объектная запись, значения LineInfo, объект) \ r \ n в FileHelpers.FileHelperEngine 1.ReadStreamAsList(TextReader reader, Int32 maxRecords, DataTable dt)\r\n at FileHelpers.FileHelperEngine 1.ReadStream (читатель TextReader, Int32 maxRecords) \ r \ n в FileHelpers.FileHelperEngine`1.ReadString (источник строк, Int32 maxRecords) ... 

[FieldTrim(TrimMode.Both)]
[FieldConverter(ConverterKind.Date, "MM-dd-yyyy hh:mm")]
public DateTime Transaction_date; //where Transaction_date CSV value = "2019-01-02 6:00" Note that formatter is not universal date format

Это исключение дляфрагмент bove:

«Сообщение»: «Произошла ошибка.», «ExceptionMessage»: «Ошибка преобразования« 2009-01-02 06:00 »в тип:« DateTime ». Использование формата: «MM-дд-гггг чч: мм», «ExceptionType»: «FileHelpers.ConvertException», «StackTrace»: «в FileHelpers.ConvertHelpers.DateTimeConverter.StringToField (String from) \ r \ n в FileHelpers. FieldBase.AssignFromString (ExtractedInfo fieldString, строка LineInfo) \ r \ n в FileHelpers.FieldBase.ExtractFieldValue (строка LineInfo) \ r \ n в FileHelpers.RecordOperations.StringToRecord (запись объекта, строка LineInfo, значения Object []) \ r \ nв FileHelpers.FileHelperEngine 1.ReadStreamAsList(TextReader reader, Int32 maxRecords, DataTable dt)\r\n at FileHelpers.FileHelperEngine 1.ReadStream (читатель TextReader, Int32 maxRecords) \ r \ n в FileHelpers.FileHelperEngine`1.ReadString (источник строк, Int32 maxRecords) ...

1 Ответ

2 голосов
/ 18 октября 2019

Согласно этим документам , вы можете использовать ConverterKind.DateMultiFormat, чтобы разрешить до трех форматов. 

[FieldConverter(ConverterKind.DateMultiFormat, "yyyy-MM-dd HH:mm", "MM-dd-yyyy HH:mm")]

Обратите внимание, что в вашем коде было hh. Это относится к часам 12-часовых часов в диапазоне от 01 до 12. Это не очень полезно без указания tt для индикатора меридиоза am / pm. Вы, вероятно, имели в виду HH, что соответствует часам 24-часовых часов в диапазоне от 00 до 23. Токены форматирования чувствительны к регистру.

В конечном счете, указанные вами форматы передаются в DateTime.TryParseExact в исходном коде здесь . Таким образом, можно использовать любую из строк формата даты и времени .NET .

Относительно вашего вопроса:

... если оно сможет принятьлюбая правильная строка даты ...

Нет. Он будет принимать только предоставленные вами форматы.

Имейте в виду, что строки дат могут быть неоднозначными, если культура неясна. Например, 01/02/2019 будет 2 января в США, но будет интерпретироваться как 1 февраля в большей части остального мира.

...