Получить смещение UTC из TimeZoneInfo.Local.StandardName

Question

Я делаю приложение для ios с использованием Xamarin, которое используется во всем мире (в настоящее время в США, Европе и Африке).

Это приложение отправляет зарегистрированные данные на сервер, и пользователи хотятПосмотрите время данных, локализованных для регистрации.

Итак, я решил сохранить DateTime.UtcNow в базе данных вместе с именем часового пояса, поэтому я использовал TimeZoneInfo.Local.StandardName и подумал, что будуиспользуйте эти два поля для отображения даты и времени utc, локализованных для часового пояса, но у меня возникли некоторые проблемы.

Как я могу получить смещение часового пояса из этого "StandardName", вот некоторые из значений, которые яполучение от Xamarin на iOS: «CET», «WAT» (я думаю, Конго), «EST» и «+0545» (что это такое ???)

ИЛИ следует вместо этого сохранить смещение,который я предполагаю, должно быть легко получить на каждом устройстве?

Answer 1

Если вам нужно сохранить идентификатор часового пояса, сохраняйте TimeZoneInfo.Id, а не StandardName.Я ожидаю, что идентификаторы часовых поясов в любой системе на базе Unix будут выглядеть как «Европа / Лондон» и т. Д. (Это формат IANA ID.)

Тогда вы должны бытьвозможность вернуть часовой пояс снова, используя TimeZoneInfo.FindSystemTimeZoneById.Но обратите внимание, что не будет работать , если вы попытаетесь получить часовой пояс по идентификатору IANA в Windows или часовой пояс по идентификатору Windows в Unix.Если это проблема, вы можете рассмотреть возможность использования согласованной базы данных часовых поясов повсеместно, потенциально используя мой проект Noda Time , который поставляется с включенной в него базой данных IANA.Затем вы можете использовать это как на компьютерах с Unix, так и на Windows.

Вместо этого было бы неплохо сохранить смещение, если оно относится к текущему или прошлому событию.Хранить его для события future рискованно, потому что это означает, что вы не сможете предпринять какие-либо действия, если изменятся правила часового пояса.Даже хранение значения UTC и идентификатора часового пояса также может быть рискованным: если вы хотите представить «9:00 в Париже 1 февраля 2025 года», то вы, вероятно, хотите хранить именно эту информацию, а не «UTC».мгновение, которое я в настоящее время предсказываю, перейдет в 9:00 в Париже ".