Спецификация DateTime.Now и культура/Timezone

Ответ 1

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

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

Хостинг сервера должен быть неактуальным - вы никогда не должны использовать часовой пояс сервера. Тем не менее, вам нужно будет знать соответствующее UTC-смещение (или часовой пояс) для пользователя. Это невозможно сделать на основе только культуры - вы захотите использовать Javascript на пользовательской машине, чтобы определить смещение UTC в то время, когда вас интересует (не обязательно "сейчас" ).

Как только вы определили, как сохранить это значение, получить его просто: если вы уже сохранили время UTC и смещение, вы просто применяете это смещение, и вы вернетесь в исходное местное время пользователя, Вы не сказали, как вы конвертируете значения в текст, но просто должны просто просто отказаться - просто отформатируйте значение, и вы должны получить исходное местное время.

Если вы решили использовать Noda Time, вы просто используете OffsetDateTime вместо DateTimeOffset.

Ответ 2

Стандартный подход заключается в том, чтобы всегда хранить данные времени в формате UTC, если важный момент времени имеет важное значение. На это время не влияют изменения и культуры часовых поясов.

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

Обратите внимание, что для веб-кейсов (например, ASP.Net) вам может понадобиться сначала определить культуру пользователя/часовой пояс и отправить его на сервер (поскольку эта информация не требуется в запросах GET) или форматирование времени в браузер.

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

Примечание. Культура и часовой пояс не связаны друг с другом, поэтому вам нужно решить, как вам нужно обрабатывать такие случаи, как IN-IN culture в часовом поясе PST США.

Ответ 3

Меня немного смущает формулировка вашего вопроса, но кажется, что вы хотите определить часовой пояс своего пользователя.

• Вы просили расспросить их? Во многих приложениях пользователь выбирает свой часовой пояс в пользовательских настройках.

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

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

Если вы спуститесь по этому маршруту, вам нужно будет использовать часовые пояса IANA/Olson, где находится Noda Time в игру. Вы можете получить к ним доступ из DateTimeZoneProviders.Tzdb.

Место размещения не имеет значения, если вы используете UTC. Это хорошая вещь.

Кроме того, если вы используете Noda Time, то вам, вероятно, следует использовать SystemClock.Instance.Now вместо DateTime.UtcNow.

См. также здесь и здесь.

Кроме того, альтернативным решением было бы просто передать время UTC браузеру и загрузить его в объект JavaScript Date. Браузер может преобразовать это в локальное время пользователя. Вы можете также использовать библиотеку, например moment.js, чтобы сделать это проще.

Update

Относительно вашего подхода к отображению кодов культуры в часовые пояса:

<appSettings>
    <add key="sv-se" value="W. Europe Standard Time" />
    <add key="ta-IN" value="India Standard Time" />
</appSettings>

Это не сработает по нескольким причинам:

• Многие люди используют разные настройки культуры на своем компьютере, чем область, в которой они физически находятся. Например, я мог бы быть американским-американским докладчиком, живущим в Германии, мой код культуры, вероятно, все еще en-US, а не de-DE.

• Код культуры, содержащий страну, используется для различения диалектов языка. Когда вы видите es-MX, это означает "испанский, как говорят в Мексике". Это не означает, что пользователь фактически находится в Мексике. Это просто означает, что пользователь говорит о диалекте испанского языка по сравнению с es-ES, что означает "испанский, как говорят в Испании".

• Даже если страновая часть кода культуры может быть надежной, есть много стран, которые имеют несколько часовых поясов! Например, что бы вы поместили в свой список сопоставлений для en-US? Вы не можете просто предположить, что все мы находимся на восточном стандартном времени.

Теперь я объяснил, почему ваш нынешний подход не будет работать, я настоятельно рекомендую вам взять мой первоначальный совет. Очень просто:

• Определите часовой пояс пользователя, желательно, спросив их, возможно, с некоторой помощью одной из утилит, с которыми я связан выше.

• Вы сохраняете UTC, поэтому просто перейдите в этот часовой пояс для отображения.

  Использование временных зон Microsoft

  TimeZoneInfo tz = TimeZoneInfo.FindSystemTimeZoneById("W. Europe Standard Time");
  DateTime localDatetime = TimeZoneInfo.ConvertTimeFromUtc(yourUTCDateTime, tz);
  

  Использование временных зон IANA и времени Noda

  DateTimeZone tz = DateTimeZoneProviders.Tzdb["Europe/Stockholm"];
  Instant theInstant = Instant.FromDateTimeUtc(yourUTCDateTime);
  LocalDateTime localDateTime = theInstant.InZone(tz);
  

Ответ 4

Мы столкнулись с аналогичной проблемой с приложением, над которым я работал в последнее время. Во время разработки каждый находился в одном и том же часовом поясе, и проблема не была замечена. И в любом случае было много устаревшего кода, который был бы болью для изменения, не говоря уже о преобразовании всей информации о дате, которая уже была в БД. Поэтому переход на DateTimeOffset не был вариантом. Но нам удалось добиться этого, переходя от времени сервера к пользовательскому времени на выходе и перехода от времени пользователя к серверному времени на пути. Важно также делать это с любыми сравнениями времени, которые были границей. Поэтому, если пользователь ожидал, что какое-то время истечет в полночь, тогда мы будем конвертировать это время в серверное время и делать все сравнения во время сервера. Это звучит как много работы, но гораздо меньше работы, чем преобразование всего приложения и БД для использования DateTimeOffsets.

Слух - это поток, который похож на несколько хороших решений для часового пояса.

Определите часовой пояс пользователя

Ответ 5

Если вы хотите показать согласованную историю даты и времени для пользователя, независимо от языкового стандарта, из которого они просматривают историю, выполните следующие действия:

• Во время Save сохраняйте не только дату/время создания "UTC", но и обнаруженную локаль
• Использовать сохраненный saved from locale для вычисления исходной даты/времени и испускать строку для отображения (т.е. не использовать текущую локаль пользователя, когда вы ее разворачиваете).

Если у вас нет возможности изменить ваше хранилище, возможно, вы можете изменить свою отправку, чтобы отправить "текущее клиентское время", сохранить его буквально (не конвертировать в UTC), а затем отобразить буквально (не конвертировать к обнаруженной культуре)

Но, как я говорю в своем комментарии по вашему вопросу, я не уверен, что правильно понял ваши требования.