Является ли информация о часовом поясе избыточной при наличии метки времени в формате UTC?

У меня есть простое мобильное приложение, которое планирует будущие события между людьми в указанном месте. Эти события могут быть физическими или виртуальными, поэтому время, указанное для события, может или не может находиться в том же часовом поясе, что и «место» события. Например, физическая встреча может быть назначена для двух человек в Лондоне на 10 часов утра по местному времени в указанный день. В качестве альтернативы, звонок в Skype может быть запланирован для двух человек в разных часовых поясах в 16:00 (в часовом поясе одного человека) в указанную дату, хотя «местом» события является просто «офис», что означает два разных места в разных часовых поясах.

Интересно, что для этого приложения подойдет следующий дизайн:

  1. На клиенте он просит пользователя ввести местную дату и время и указать часовой пояс, локальный для события.

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

  3. Когда клиент извлекает эти данные, он получает только временную метку UTC и преобразует ее в местное время в том же часовом поясе, что и текущий часовой пояс клиента. Текущий часовой пояс клиента определяется текущим параметром часового пояса системы, который, я думаю, автоматически настраивается в зависимости от местоположения клиента (конечно, при условии, что клиент подключен к мобильной сети).

Мои основные мотивы для этого дизайна:

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

  2. Пользователи заботятся только о местной дате и времени в часовом поясе, в котором они сейчас находятся.

Это осуществимый дизайн? Если нет, то какие конкретные сценарии могут нарушить работу приложения или серьезно повлиять на взаимодействие с пользователем? Критика приветствуется.


time timestamp datetime timezone timestamp-with-timezone
person skyork    schedule 22.06.2015    source источник

Ответы (2)


arrow_upward
5
arrow_downward

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

Для повторяющихся событий вам необходимо знать часовой пояс, в котором они повторяются ... не только смещение UTC, но и фактический часовой пояс. Например, если я назначу еженедельную встречу с коллегами из Америки / Лос-Анджелеса в 17:00 в Европе / Лондоне, то большую часть года для них она будет проводиться в 9:00 ... но на пару дней недели в году это будет происходить в 8 утра, а в течение нескольких недель в году это будет происходить в 10 утра, из-за различий в том, когда наблюдается летнее время.

Даже для одного события вы можете подумать, что произойдет, если правила часовых поясов изменятся. Предположим, я назначу встречу на 16:00 20 марта 2018 года по часовому поясу Европа / Лондон. В настоящее время это произойдет со смещением UTC, равным 0 ... но предположим, что между настоящим моментом и встречей правила часовых поясов изменятся, чтобы ввести британское летнее время на час раньше. Если я записал это в своем дневнике как 16:00, я, вероятно, не хочу, чтобы программа думала, что на самом деле это 17:00, потому что это момент UTC, который мы изначально предсказывали.

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

person Jon Skeet    schedule 22.06.2015

arrow_upward
1
arrow_downward

Чтобы не усложнять, мои ответы таковы:

  • Информация о часовом поясе избыточна, если вы хотите определить отдельный момент. Временная метка UTC / Unix полностью определяет момент.

  • Ваш дизайн кажется выполнимым, но в пункте 2: я бы конвертировал в метку времени UTC / Unix на стороне клиента и уже передал эту метку времени в ее окончательной форме серверу. Причина: на стороне клиента уже есть информация, необходимая для преобразования (см. хронометрирующий клиент- пример архитектуры server-db - работает именно на тех принципах, которые вы описываете).

  • Одна из возможных проблем (как описано Джоном Скитом в его ответе) - это повторяющиеся события, но это должно отражаться на вашем способе моделирования времени. Разница между повторяющимися событиями и фиксированными событиями заключается в том, что последние полностью определяют момент (например, временная метка UTC / Unix), в то время как первые являются только «функцией», которая может применяться к текущему времени, чтобы получить время следующего триггера повторяющегося событие. Но это может быть совсем другая проблема, чем та, о которой вы спрашиваете - в любом случае, отличить повторяющиеся события (если они вам нужны) и фиксированные события в вашей модели - хорошая идея.

  • Одно из решений, которое следует принять: ТЯНИТЬ или ТЯНИТЬ? Или оба? Вы хотите, чтобы сервер мог отправлять электронные письма, например, при наступлении события? Или вам нужны клиентские оповещения только тогда, когда ваше клиентское приложение запущено? Ответы на эти вопросы помогут вам прийти к подходящему для вас дизайну.

person Sandman    schedule 22.06.2015