Дополнительные пакеты для использования с NodaTime - PullRequest
Новая
       26

Дополнительные пакеты для использования с NodaTime

0 голосов
/ 12 декабря 2018

Я обновляю приложение, чтобы использовать NodaTime , чтобы исправить многие существующие проблемы времени с нашими данными и процессами.

Мне нужно будет разрешить часовые пояса из мобильного приложения, которое отправляет имена часовых поясов IANA,Мне нужно будет поддерживать преобразования в UTC с использованием пользовательских смещений (т. Е. Жестко запрограммированных -04: 00).Мне также может понадобиться или не поддерживать имена часовых поясов Windows.

Для всего этого мне интересно, нужны ли мне дополнительные пакеты.Как TimeZoneConverter и TimeZoneNames работают вместе с NodaTime?Существуют ли какие-либо дополнительные пакеты, которые я должен использовать вместе с NodaTime?

Наша конечная цель - сохранить все данные в виде Utc и преобразовать их в пользовательское время только для отображения или принятия пользовательского ввода.

1 Ответ

0 голосов
/ 12 декабря 2018

Насколько я понимаю, вам не нужны никакие дополнительные пакеты для этого сценария.

  • Для идентификаторов IANA просто используйте DateTimeZoneProviders.Tzdb
  • для "необработанного смещения"«Идентификаторы, вы можете использовать любого провайдера часового пояса, запрашивая идентификатор в форме« UTC + 01: 00 »и т. Д. (Поэтому вам нужно добавить префикс« UTC ».)
  • Для Windowsсопоставление зон, вы можете использовать TzdbDateTimeZoneSource.Default для получения информации TZDB по умолчанию, а затем использовать свойство WindowsMapping, чтобы получить объект WindowsZones, который можно использовать для сопоставления.

TimeZoneConverter может быть проще использовать для последнего пункта, но это не обязательно.Идентификаторы IANA, которые он предоставляет , должны нормально работать с Noda Time.

TimeZoneNames больше о отображении имен часовых поясов для пользователей.Если вам это не нужно, вам, вероятно, не нужен пакет.

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

Предположим, что пользователь говорит, что хочет запланировать мероприятие для Европы / Парижа на 9 часов утра 1 декабря 2021 года. Если вы преобразуете его в UTC сейчас , выв конечном итоге с 2021-12-01T08: 00Z, потому что текущие правила о часовых поясах говорят, что Париж будет на UTC + 1 в декабре 2021 года.

Однако вполне возможно, что с настоящего момента до 2021 года, Францияизменил правила своего часового пояса, чтобы использовать «постоянное дневное время», т.е. UTC + 2 круглый год.В этот момент ваше значение UTC 2021-12-01T08: 00Z будет соответствовать 10:00 утра в Париже на указанную дату - вопреки тому, что указал пользователь.

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

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

...