Как решить проблему с разными часовыми поясами пользователей?
Допустим, в приложении есть какой-то ивент, который можно выполнить раз в сутки. Обновляется для использования он в 00:00. Важно проверять то, что пользователь делает его каждый день(Для того, что отслеживать стрик), поэтому нужно хранить дату предыдущего выполнения.
Как обработать на бэкенде время людей из разных часовых поясов?
Если привязать бэк к конкретному часовому поясу, тогда в разных частях планеты будет разное время обновления, что не очень приятно.
Хранить дату предыдущего ивента в часовом поясе юзера:
1. Если привязать приложение к локальному времени устройства, то можно будет мотать время и накручивать статистику.
Хотя здесь можно будет поставить проверку, чтобы нельзя было присылать "результаты из будущего"
2. Если в приложении привязаться к времени с интернета, то есть для каждого юзера хранить дату предыдущего ивента в его часовом поясе, тогда как поступить, если пользователь поменяет местоположение и часовой пояс сдвинется, например, часов на 12 вперёд при перелёте в новое место, а значит, что имеется возможность, что из-за этого пользователь пропустит один день на выполнение ивента и его стрик сбросится только потому что его предыдущая дата на сервере и пришедшая вновь имею огромную разницу во времени из-за смены местоположения человека. Хотя по факту для самого человека суток ещё не прошло
upd. Основной проблемой остаётся то, как сохранить пользователю стрик, если он поменяет местоположение на условном самолёте, если на бэке хранится дата его старого часового пояса. Допустим, сегодня он ещё не делал ивент, но прилетел в место, где уже наступил новый день. Хотя по его старому времени, где он был раньше, он ещё успевает сделать и сохранить свой прогресс. И фактически с предыдущей сохранённой даты ещё не прошло 24 часа
Это касается как веб версии приложения, так и мобильной. Какие есть решения?
По мне, так самое простое и справедливое зафиксировать одно время на всех, да, у кого-то это будет полночь, у кого-то три часа дня, но зато это не зависит от перелётов, перехода на летнее время и прочих несоответствий.
Но вообще задача не имеет однозначного решения. Надо взвешивать плюсы и минусы и выбирать что в вашем случае важнее. Например учёт часовых поясов открывает простор для читеров, например я не успел что-то сделать в Москве, перевожу часовой пояс на Нью-Йорк и у меня есть ещё семь часов.
Чтобы отвязаться от часовых поясов, посмотрите на проблему иначе: пусть «серией побед», считаются победы каждые 3 часа. Как в таких условиях вы определяли бы границы: когда уже можно засчитать новое событие, и когда аккаунт опоздал и серия прервалась? Изначально дан только timestamp первого события юзера.
Как раз для таких ситуаций придумали GMT(UTC), в котором, кстати, и хранится (при правильной архитектуре) время события. А то, что пользователь видит время в соответствии с его настройками часового пояса - уже его проблемы.
Если привязать бэк к конкретному часовому поясу, тогда в разных частях планеты будет разное время обновления, что не очень приятно.
1. Зато одновременно у всех.
2. Пользователь не знает какое время у сервера, не знает во сколько сброс. Ему надо сообщить во сколько будет сброшена статистика и основываясь на этих данных, он подберет удобное для себя время.
Еще можно для каждого пользователя завести его личный таймер. Принцип тот-же.
Не понимаю, зачем так заморачиваться вообще. Что мешает просто объявить пользователям, что граница суток проходит в полночь по Гринвичу или по Москве - и все?
Ради пары стюардесс, у которых сутки резиновые, морочить голову себе и пользователям?
Ну как раз-таки пользователям никто голову морочить не будет, хоть в африке, хоть в Лондоне при удачной реализации системы у пользователя будет обновляться возможность ивента в 12 часов ночи.
Ну какбэ не заморачиваться.
Хранить часовой пояс пользователя, работать по серверному UTC времени.
Разрешить менять часовой пояс пользователю только раз в день(неделю\месяц) и только руками в настройках.
При смене часового пояса юзера - смотреть, чтоб это не сбросило ему "стрик", сдвинув в ту или иную сторону, но не чаще/реже чем N(сверить с датой последнего пройденного) - тут уж сами смотрите, как у вас там что, но не думаю, что это будет сложнее пары if'ов.
Ну и предупреждение юзеру мол "Внимание, при смене ЧП следующий эвент будет тогда-то".
Простой
Средний
Простой
