TimeZone vs Offset для хранения часового пояса пользователя

Я понимаю, что это часто задаваемый вопрос, но я не смог найти никаких сообщений, указывающих на недостатки использования/сохранения смещения для часового пояса пользователя. Разве это не лучший и более эффективный способ?

Длинные выпадающие списки часовых поясов неудобны для пользователя, и в большинстве таких списков все равно не указаны все города. Они также требуют, чтобы пользователь указал свой часовой пояс. Я чувствую, что может быть гораздо лучше просто обнаружить это. В моем случае мое приложение представляет собой приложение ASP.NET Core с интерфейсом Reach, и с помощью JavaScript довольно легко зафиксировать смещение часового пояса пользователя.

Любая причина, по которой сохранение смещения часового пояса пользователя НЕ является хорошей идеей?


person Sam    schedule 20.10.2017    source источник
comment
Часовой пояс и смещение это не одно и то же. Одно и то же смещение может использоваться более чем в 1 часовом поясе, и один и тот же часовой пояс может иметь более 1 смещения в истории из-за перехода на летнее время (или просто потому, что они решил перейти на другое смещение) . Поскольку это отношение N-к-N, сохранение только смещения даст вам подсказку (список возможных зон), но не точную зону.   -  person    schedule 20.10.2017
comment
Честная оценка. Я думаю, что окончательный ответ зависит от потребностей человека. В моем случае я просто хочу отобразить все значения даты и времени в текущем часовом поясе пользователя, чтобы они были понятны пользователю. Это включает в себя те случаи, когда пользователь находится за пределами своего домашнего часового пояса, но все еще использует мое приложение. Я чувствую, что обнаружение изменения смещения и автоматическое отображение всех значений даты/времени в текущем часовом поясе пользователя довольно удобно. Однако может быть хорошей идеей отображать уведомление при обнаружении изменения.   -  person Sam    schedule 20.10.2017
comment
В этом случае вы можете хранить все в UTC и конвертировать в часовой пояс пользователя при отображении   -  person    schedule 20.10.2017
comment
Точно. В настоящее время я храню все значения даты/времени в формате UTC, а также сохраняю часовой пояс пользователя. Но все больше и больше я чувствую, что мне не нужен часовой пояс пользователя. Все, что мне нужно, это смещение для моего преобразования.   -  person Sam    schedule 20.10.2017
comment
На самом деле часовой пояс — это набор всех смещений, которые регион имел, имеет и будет иметь в течение истории (включая изменения летнего времени), поэтому только с часовым поясом вы можете получить правильное смещение для каждого момента UTC.   -  person    schedule 20.10.2017


Ответы (1)


Любая причина, по которой сохранение смещения часового пояса пользователя НЕ является хорошей идеей?

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

... В моем случае я просто хочу отобразить все значения даты и времени в текущем часовом поясе пользователя, чтобы они были значимы для пользователя.

Итак, допустим, вы проверяете текущее смещение часового пояса пользователя, и это UTC-7. Итак, вы применяете это к некоторым датам и времени в своем приложении и готово - так вы думаете. За исключением того, что вы не учли, что пользователь находится в Калифорнии, а одна из ваших дат приходится на декабрь, когда смещение должно быть UTC-8.

Итак, вы пытаетесь исправить это и работаете по правилу «когда я вижу -7, иногда может быть -8». За исключением того, что теперь у вас появился пользователь, который находится в Колорадо, где зимой -7, а летом -6. Или другой пользователь из Аризоны, где большая часть штата находится в -7 в течение всего года. Как узнать, какому набору правил следовать? Без ссылки на фактический часовой пояс это невозможно.

Это становится еще более сложным во всем мире. Например, количество вариаций для UTC+2 просто сумасшедшее. Даже для стран, которые переключаются между UTC+2 и UTC+3 — они не все переключаются в одни и те же даты или в одно и то же время суток!

См. также: Проблема со временем и часовыми поясами — Computerphile (YouTube) и вики тега StackOverflow timezone.

person Matt Johnson-Pint    schedule 21.10.2017
comment
Мэтт, спасибо за подробный ответ. Я думаю, что ключом к удобному для пользователя приложению является постоянная проверка смещения часового пояса пользователя и отображение значений даты/времени с текущим смещением. Очевидно, что все значения даты/времени должны храниться в формате UTC в базе данных. - person Sam; 21.10.2017
comment
Скажем, база пользователя находится в Денвере, но он отправился в Лос-Анджелес. Когда его ноутбук подключается к Интернету, скорее всего, он обновит часовой пояс, и мое веб-приложение обнаружит новое значение смещения и отобразит значения даты/времени в текущем часовом поясе пользователя. - person Sam; 21.10.2017
comment
Конечно, но это смещение применимо только сейчас. Это не обязательно относится ко вчерашнему или завтрашнему дню или любому другому произвольному моменту времени. - person Matt Johnson-Pint; 21.10.2017
comment
Я определенно вижу вашу точку зрения, и она верна. Здесь приложение должно принимать собственные решения. Скажем, у нашего пользователя из Денвера была встреча в 14:00 по тихоокеанскому времени в июле. Затем он навсегда переезжает в Сиэтл и решает проверить в своем календаре прошлые события, которые произошли в июле. Должен ли календарь показывать время начала события в 14:00, потому что когда оно произошло, это было в 14:00 в Денвере, или показывать его как 13:00, потому что наш пользователь сейчас находится в тихоокеанском времени. Я бы сказал, что все времена прошлого, настоящего и будущего всегда должны отображаться в текущем времени пользователя. Это означает, что нужно всегда проверять текущее смещение пользователя. - person Sam; 21.10.2017