lssssssssssl
@lssssssssssl

Как решить проблему с разными часовыми поясами пользователей?

Допустим, в приложении есть какой-то ивент, который можно выполнить раз в сутки. Обновляется для использования он в 00:00. Важно проверять то, что пользователь делает его каждый день(Для того, что отслеживать стрик), поэтому нужно хранить дату предыдущего выполнения.

Как обработать на бэкенде время людей из разных часовых поясов?
Если привязать бэк к конкретному часовому поясу, тогда в разных частях планеты будет разное время обновления, что не очень приятно.

Хранить дату предыдущего ивента в часовом поясе юзера:

1. Если привязать приложение к локальному времени устройства, то можно будет мотать время и накручивать статистику.
Хотя здесь можно будет поставить проверку, чтобы нельзя было присылать "результаты из будущего"

2. Если в приложении привязаться к времени с интернета, то есть для каждого юзера хранить дату предыдущего ивента в его часовом поясе, тогда как поступить, если пользователь поменяет местоположение и часовой пояс сдвинется, например, часов на 12 вперёд при перелёте в новое место, а значит, что имеется возможность, что из-за этого пользователь пропустит один день на выполнение ивента и его стрик сбросится только потому что его предыдущая дата на сервере и пришедшая вновь имею огромную разницу во времени из-за смены местоположения человека. Хотя по факту для самого человека суток ещё не прошло

upd. Основной проблемой остаётся то, как сохранить пользователю стрик, если он поменяет местоположение на условном самолёте, если на бэке хранится дата его старого часового пояса. Допустим, сегодня он ещё не делал ивент, но прилетел в место, где уже наступил новый день. Хотя по его старому времени, где он был раньше, он ещё успевает сделать и сохранить свой прогресс. И фактически с предыдущей сохранённой даты ещё не прошло 24 часа

Это касается как веб версии приложения, так и мобильной. Какие есть решения?
  • Вопрос задан
  • 546 просмотров
Решения вопроса 4
alexgp13
@alexgp13
Руководитель ИТ-проектов
Как раз для таких ситуаций придумали GMT(UTC), в котором, кстати, и хранится (при правильной архитектуре) время события. А то, что пользователь видит время в соответствии с его настройками часового пояса - уже его проблемы.
Ответ написан
profesor08
@profesor08
Если привязать бэк к конкретному часовому поясу, тогда в разных частях планеты будет разное время обновления, что не очень приятно.

1. Зато одновременно у всех.
2. Пользователь не знает какое время у сервера, не знает во сколько сброс. Ему надо сообщить во сколько будет сброшена статистика и основываясь на этих данных, он подберет удобное для себя время.

Еще можно для каждого пользователя завести его личный таймер. Принцип тот-же.
Ответ написан
Комментировать
Adamos
@Adamos
Не понимаю, зачем так заморачиваться вообще. Что мешает просто объявить пользователям, что граница суток проходит в полночь по Гринвичу или по Москве - и все?
Ради пары стюардесс, у которых сутки резиновые, морочить голову себе и пользователям?
Ответ написан
Aetae
@Aetae
Тлен
Ну какбэ не заморачиваться.
Хранить часовой пояс пользователя, работать по серверному UTC времени.
Разрешить менять часовой пояс пользователю только раз в день(неделю\месяц) и только руками в настройках.
При смене часового пояса юзера - смотреть, чтоб это не сбросило ему "стрик", сдвинув в ту или иную сторону, но не чаще/реже чем N(сверить с датой последнего пройденного) - тут уж сами смотрите, как у вас там что, но не думаю, что это будет сложнее пары if'ов.
Ну и предупреждение юзеру мол "Внимание, при смене ЧП следующий эвент будет тогда-то".
Ответ написан
Комментировать
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы