C# .Net Linq и преобразование datetime в форматированное sting
У меня есть запрос
var result = (from myView in db.loginSessions
where myView.machine.ToUpper().Equals(machine.ToUpper())
&& myView.start >= myStart
&& myView.end <= myEnd
orderby myView.start
select new loginSessionList {
Id = myView.id,
Machine = myView.machine.ToUpper(),
Start = myView.start.ToString("u"),
End = myView.end.ToString("u"),
User = myView.username
}).ToList();
Я получаю исключения ArgumentOutOfRange при преобразовании даты и времени. Я пробовал разные строки преобразования ToString. Я пробовал другие преобразования даты в строку To..., предлагаемые Intellisence. Я пробовал Convert.string(myView.start). Ничего не получилось. Я погуглил и нашел совет, используя все, что я пробовал. Нужно ли мне обрабатывать сгенерированный список пост-обработкой?
Что я пропустил?
Спасибо. Это привело меня к ответу. Я имел использовал DateTime в loginSessionList, но у меня возникли проблемы. Я изменил эти записи на строки и в итоге задал вопрос выше. Моя проблема заключалась в том, что имена полей в loginSessionList когда-то были lowercase. Некоторое переформатирование кода, кажется, бесполезно для них CamelCased, и это испортило то, что получилось в результате десериализации.
Ответы 2
У меня есть 3 правила работы с DateTimes, которые мне очень пригодились:
- Всегда сохраняйте, извлекайте и передавайте значение UTC. Перевод в правильный местный часовой пояс - это задача ToString (), которая запрашивает у Windows часовой пояс пользователя. Вы не хотите добавлять часовые пояса к своим проблемам.
- Избегайте хранения, извлечения или передачи DateTimes в виде строк. По возможности храните его в правильных типах
- Если вы не можете следовать правилу 2 (например, когда вы имеете дело с сериализацией), по крайней мере выберите фиксированный формат культуры и строковую кодировку на всех конечных точках. Вы не хотите получать различные культуры или ошибочные подразумеваемые кодировки для существующих проблем.
Это первое правило - не всегда хорошая идея. Если я запланировал календарное мероприятие на «12 марта 2022 года, 15:00 по Лондону», я бы хотел, чтобы эта информация сохранялась - так что если в период с этого момента правила часовых поясов будут изменены, событие по-прежнему представляет информацию, которая предоставленный пользователем. Точно так же событие с первым наступлением «12 марта 2018 года, 15:00 в Лондоне, повторяющееся раз в неделю» действительно должно знать часовой пояс, чтобы справиться с изменениями летнего времени. Запись прошедшего момента времени (например, метки времени) через UTC - это нормально, но я бы не стал заходить слишком далеко.
@JonSkeet: вы хотите, чтобы было сохранено, что дата находится в Лондоне, и поэтому при отображении следует использовать лондонские часовые пояса. Вы действительно нет хотите сохранить что-нибудь, кроме UTC, в базе данных Backend. Имеете дело с такими деталями, как изменение часовых поясов / летнего времени? это то, что, надеюсь, уже делают форматы культуры и ToString (). В противном случае это слишком хлопотно.
Опять же, я категорически не согласен. Если у вас все хранится в формате UTC, собираетесь ли вы запустить бэкэнд-задание, которое изменит все, если правила часовых поясов когда-либо изменятся? (И правила часовых поясов делать меняются очень часто.) Мантра «хранить только в формате UTC» часто цитируется и хорошо работает в простых ситуациях, но ее недостаточно для всех приложений, и ее не следует формулировать безоговорочно, например это, ИМО.
И нет, часовой пояс полностью отделен от культуры / формата. Если правила часового пояса меняются, это изменяет когда происходит событие. Это не то же самое, что изменить просто текстовое представление.
@JonSkeet Перевод "UTC" в "часовой пояс, выбранный текущим пользователем" - это то, что делает ToString () и Windows в тысячу раз лучше, чем я когда-либо мог. Зачем мне заново изобретать колесо, когда моя рабочая машина стоит прямо там, а у меня есть ключи?
Я никогда не предлагал вам выполнить преобразование часового пояса, написав этот код самостоятельно. Для этого вам следует использовать хорошую библиотеку (я, конечно, порекомендовал бы свою библиотеку Noda Time). Но дело в том, что вы храните. Если вы попросите Windows преобразовать «12 марта 2022 года, 15:00 по Лондону» в UTC, а затем сохранить это значение UTC, вы потеряете информацию. Если правила часовых поясов изменятся в следующем году, так что (скажем) Великобритания постоянно находится в UTC + 1, информация в вашей базе данных больше не будет соответствовать тому, что пользователь попросил вас сохранить. Они попросили вас оставить магазин «12 марта 2022 года, 15:00 в Лондоне».
Для получения дополнительной информации я бы рекомендовал прочитать отличный ответ Мэтта Джонсона здесь: stackoverflow.com/questions/19626177/…
«Если в следующем году правила часовых поясов изменятся так, что (скажем) Великобритания будет постоянно находиться на UTC + 1», то это действительно зависит от того, как другая сторона с этим справится. Было ли собрание выполнено в том же всемирном координированном времени или было адаптировано к местному времени? В любом случае вы ошибаетесь в половине случаев и должны спросить другую сторону.
Это при условии, что есть «другая сторона». Вполне может не быть - это может быть даже не встреча; есть много других мероприятий. Но по сути, я привожу пример, когда пользователь доверил вам информацию о том, что что-то произойдет «12 марта 2022 года, 15:00 в Лондоне». Преобразование этого в UTC теряет информацию, поэтому я бы предложил избегать этого (или, по крайней мере, не Только, сохраняющий UTC, а не Только в отношении информации о часовом поясе как чего-то связанного со строковым представлением).
@JonSkeet: если дата закрытия фондовой биржи за пределами Великобритании и у вас есть только 1 час, чтобы отреагировать на данные, ваш Metting должен оставаться в том же всемирном координированном времени, или это бессмысленно (данных еще нет или окно возможностей прошло) . Авиакомпании / аэропорту, возможно, придется перетасовать рейсы, потому что кто-то только что изменил свои часовые пояса, в результате чего самый важный человек приедет раньше / позже. Еще одно собрание, возможно, пришлось бы перенести. Как только часовые пояса меняются, кто-то должен пройти проверку. Даже в вашем случае кому-то все равно придется пойти и изменить, что «Целевой часовой пояс» имелось в виду в БД.
Если пользователь хочет запланировать свое мероприятие в формате UTC, это нормально. Но вы, похоже, предполагаете, что знаете лучше, чем пользователь, и что пользователь, говорящий «12 марта 2022 года, 15:00 в Лондоне», на самом деле не понимает, что они имеют в виду. Я предпочитаю хранить данные, которые выразил пользователь, как окончательный источник истины. Возможно, стоит сохранить значение UTC также и пересчитать его, когда вы знаете, что меняете данные часового пояса, но то, что вы отстаиваете, - это потеря информации, и я не понимаю, как это хорошая идея.
Итак, ответ на мою проблему не имел ничего общего с Linq или .Net. @JoeEnos направил меня на правильный путь, как упоминалось в моем комментарии к его комментарию. Я создал класс для получения каждой строки результата запроса. Поля даты изначально были типа DateTime, но у меня начались проблемы. Я изменил эти поля на строку, а затем задал свой вопрос выше.
Раньше, когда у принимающего класса еще были поля DateTime, все поля имели имена в нижнем регистре. Я, должно быть, применил какое-то форматирование кода, которое CamelCased имен полей. Это означало, что после сериализации результатов имена CamelCased не могли быть найдены, и JavaScript не заботился.
Я исправил имена полей в своем js-коде, изменил типы данных полей обратно на DateTime, и все в порядке.
Спасибо
Независимо от того, нужно ли вам это или нет, почти всегда лучше использовать сильные типы (
DateTime), пока вы не будете готовы отобразить его пользователю (экран / извлечение / и т. д.). Поэтому, если возможно, эти даты должны бытьDateTimeв классеloginSessionList, и вы можете разобраться с их форматированием позже.