DateTime vs DateTimeOffset

DateTimeOffset представление мгновенное время (также известный как времени). Под этим я подразумеваю момент времени, который является универсальным для всех (не учитывая високосных секунд, или релятивистские эффекты замедление времени). Другой способ представления мгновенного времени-с помощью DateTime здесь .Kind и DateTimeKind.Utc.

это отличается от календарного времени (также известный как гражданского времени), который является позицией в чьем-то календаре, и есть много разных календарей по всему миру. Мы называем эти календари часовых поясов. Календарное время представлено символом DateTime здесь .Kind и DateTimeKind.Unspecified или DateTimeKind.Local. И .Local имеет смысл только в сценариях, где у вас есть подразумеваемое понимание того, где находится компьютер, который использует результат. (Например, рабочая станция пользователя)

Итак, почему DateTimeOffset вместо мирового DateTime? все дело в перспективе. давайте проведем аналогию-притворимся фотографами.

представьте, что вы стоите на календарной шкале времени, указывая камерой на человека на мгновенной шкале времени, выложенной перед вами. Вы выстраиваете свою камеру в соответствии с правилами вашего часового пояса - которые периодически меняются из-за летнего времени или из-за других изменений в юридическом определении вашего часового пояса. (У вас нет твердая рука, так что ваша камера трясется.)

человек, стоящий на фотографии, увидит угол, под которым появилась ваша камера. Если бы другие фотографировали, они могли бы быть под разными углами. Это Offset часть DateTimeOffset представляет.

поэтому, если вы обозначаете свою камеру "Восточное время", иногда вы указываете от -5, а иногда вы указываете от -4. Есть камеры по всему миру, все помечены разные вещи, и все показывали на одной и той же мгновенной шкале времени под разными углами. Некоторые из них находятся рядом (или поверх) друг с другом, поэтому просто зная смещение недостаточно, чтобы определить, к какому часовому поясу относится время.

а как насчет UTC? Ну, это одна камера, которая гарантированно имеет устойчивую руку. Он стоит на треноге, прочно закрепленной в земле. Это никуда не денется. Мы называем его угол зрения нулем сдвиг.

Итак-о чем же говорит нам эта аналогия? Он предоставляет некоторые интуитивные рекомендации.

• если вы представляете время относительно некоторого места в частности, представить его в календарном времени с DateTime. Просто убедитесь, что вы никогда не путаете один календарь с другим. Unspecified должно быть ваше предположение. Local полезно только исходя из DateTime.Now. Например, я мог бы получить DateTime.Now и сохранить его в базе данных - но когда я получаю его, я должен предположить, что это Unspecified. Я не могу полагаться на то, что мой локальный календарь-это тот же календарь, из которого он был первоначально взят.

• если вы всегда должны быть уверены в моменте, убедитесь, что вы представляете мгновенное время. Используйте DateTimeOffset чтобы применить его, или использовать UTC DateTime по Конвенции.

• Если вам нужно отслеживать момент мгновенного времени, но вы хотите также знать, " в какое время пользователь думал это было в их местном календаре?- ...тогда ты должны использовать DateTimeOffset. Это очень важно для систем хронометража, например - как для технических, так и для юридических вопросов.

• Если вам когда-нибудь понадобится изменить ранее записанный DateTimeOffset - У вас недостаточно информации только в смещении, чтобы гарантировать, что новое смещение по-прежнему актуально для пользователя. Вы должны и хранить идентификатор часового пояса (думаю-мне нужно имя этого камера, чтобы я мог сделать новый снимок, даже если положение изменилось).

  следует также отметить, что Нода Времени имеет представление под названием ZonedDateTime для этого, в то время как библиотека базовых классов .Net не имеет ничего подобного. Вам нужно будет хранить оба a DateTimeOffset и TimeZoneInfo.Id значение.

• иногда вы захотите представить календарное время, которое является локальным для "того, кто смотрит на него". Например, при определении что средства. Сегодня ВСЕГДА полночь до полуночи, но они представляют собой почти бесконечное число перекрывающихся диапазонов на мгновенной временной шкале. (На практике у нас есть конечное число часовых поясов, но вы можете выразить смещения вплоть до тика) поэтому в этих ситуациях убедитесь, что вы понимаете, как ограничить "кто спрашивает?"вопрос до одного часового пояса, или иметь дело с переводом их обратно в мгновенное время, как соответствующий.

вот еще несколько маленьких кусочков о DateTimeOffset Это подтверждает эту аналогию, и некоторые советы для поддержания его прямо:

• если сравнивать два DateTimeOffset значения, они сначала нормализуются до нулевого смещения перед сравнением. Другими словами,2012-01-01T00:00:00+00:00 и 2012-01-01T02:00:00+02:00 относятся к одному и тому же мгновенному моменту и поэтому эквивалентны.

• если вы делаете любое испытание блока и нужно быть некоторые из смещения, тест и the DateTimeOffset значение, а .Offset собственность отдельно.

• существует одностороннее неявное преобразование, встроенное в .Net framework, которое позволяет передавать DateTime в любом DateTimeOffset параметр или переменная. При этом the .Kind вопросы. Если вы передадите вид UTC, он будет переноситься с нулевым смещением, но если вы передадите либо .Local или .Unspecified, это будет считать местные. Структура в основном говорит: "Ну, вы попросили меня преобразовать календарное время в мгновенное время, но я понятия не имею, откуда это взялось, поэтому я просто собираюсь использовать местный календарь."Это огромный gotcha, если вы загружаете неопределенный DateTime на компьютере с другим часовым поясом. (ИМХО-это должно вызвать исключение - но это не так.)

Промоушен:

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