Как синхронизировать таймзону между фронтендом и бэкендом?
Часовые пояса часто заставляют задуматься как с ними правильно работать.
В большинстве случаев при проектировании API принято использовать или unixtime или датувремя с указанием часового пояса, но мой вопрос не про это.
Мой вопрос относится к API для фронтенда (т.е. речь идет не про RESTful API для server-to-server взаимодействия, а про API для фронтендов к которому одно из приоритетных требований - это минимизация количества запросов).
Например, есть метод который должен выдать список задач на сегодня. Понятие "сегодня" зависит от текущей таймзоны. Как бэкенду определить текущую таймзону фронтенда? Мои варианты:
1. Посмотреть в профиле пользователя, какая там указана таймзона. С профилем есть две проблемы: во-первых, пользователи очень редко выбирают свою таймзону, во-вторых, даже если пользователь указал правильную таймзону в профиле (или, например, её удалось как-то автоматически определить при регистрации), пользователь может поехать (или вообще переехать) в другой часовой пояс.
2. В метод списка задач на сегодня нужно явно передать таймзону, что-то вроде: GET /tasks/today?offset=+03:00
ИМХО выглядит как какой-то костыль.
3. Добавить ко всем запросам в API заголовок что-то вроде Current-User-Offset: +03:00
Если заголовок не передан, ориентироваться на значение по умолчанию (например, на таймзону из профиля).
4. API спроектирован неправильно, таких проблем быть вообще не должно. Например, нужен метод с получением списка задач, а какие из задач отнести к "сегодняшним" решает фронтенд.
Например, есть метод который должен выдать список задач на сегодня. Понятие "сегодня" зависит от текущей таймзоны. Как бэкенду определить текущую таймзону фронтенда?
В запросе указывать дату и время в стандартном формате - либо UTC либо местное время и таймзона: т.е., клиент запрашивает данные не за абстрактное "сегодня", а в четко определенном интервале времени. Например, за день такой-то с такого-то времени в течении суток или до дня такого-то.
Мне кажется что такой подход больше подходит для server-to-server взаимодействия.
У меня вопрос про API для фронтов, тут немного другая история.
Например, если список задач запрашивается на "сегодня", бэк может увидеть что между задачами есть какой-то перерыв и может предложить сходить в этот перерыв, например, в театр или кино. Но чтобы реализовать такую логику, бэк должен точно знать что задачи запрашиваются именно на "сегодня", т.к., если задачи запрашиваются на "вчера", то предлагать куда-то сходить бессмысленно.
При server-to-server взаимодействии это было бы два разных запроса: дай список задач с такого-то по такое-то время, дай список мероприятий.
"Кажется" тут несколько неуместно. Есть задача получения данных за определенное время - выбираем время и за это время запрашиваем данные. Все. "Сегодня", "Завтра" - понятия абстрактные и зависят от кучи факторов. Поэтому, с точки зрения пользователя он запрашивает данные за "сегодня", а вот уже код определяет вот эти факторы "сегодня" в виде точных данных и на основе этих данных выдает пользователю точный и ожидаемый результат. Тащить непосредственно в АПИ абстрактные и неопределенные понятия - не самый верный подход. Т.о. в вашем случае, да и в общем тоже, запрос должен быть например таким: GET /tasks/day/08.09.22+03:00
Т.е. запрашиваем задачи за сутки, за такое-то число и в такой-то тайм-зоне относительно времени UTC. Опять же, тут тоже могут быть ньюансы: менеджер в Москве, исполнитель задачи - во Владивостоке. И в обоих случаях список задач за "сегодня" может отличаться. Опять же, задачи могут быть привязаны к глобальному времени, а могут быть к локальному. Например, первый вариант: небольшой разброс в часовых поясах и работники работают в примерно в одно время, но каждый с небольшим локальным смещением, а все задачи находятся в условленной тайм-зоне. Пример два: разброс в часовых поясах большой и задачи привязываются к локальной дате и список задачи за вчера для Москвы и Вашингтона будет одинаковым.
Когда у меня была похожая задача с несколькими часовыми поясами и отображением данных для разных часовых поясов, то я во-первых сделал настройку в профиле пользователя "таймзона" - автоматически или вручную, во-вторых запрашивал данные из АПИ именно с указанием даты и таймзоной.
Простой
Сложный
Простой
