Руководства

Создаём выбор часового пояса с поясом посетителя по умолчанию

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

Определение пояса

Эндпоинт /v1/ip сразу возвращает поле timezone, поэтому один вызов даёт и местоположение, и идентификатор часового пояса без отдельного обращения к эндпоинту часовых поясов.

GET /v1/ip?ip=203.0.113.88
{
  "status": "ok",
  "ip": "203.0.113.88",
  "version": 4,
  "found": true,
  "country": "Australia",
  "country_code": "AU",
  "region": "New South Wales",
  "city": "Sydney",
  "postcode": "2000",
  "lat": -33.8688,
  "lon": 151.2093,
  "timezone": "Australia/Sydney",
  "asn": 7890,
  "org": "Example Networks"
}

Предварительный выбор в списке

Установите значение timezone из этого ответа как выбранный вариант в форме настроек при её первой отрисовке, на стороне сервера, до того как страница попадёт к посетителю. Это работает одинаково, будь то выпадающий список стандартных идентификаторов поясов или список с поиском, поскольку заранее выбираемое значение представляет собой обычную строку стандартного идентификатора, как в примере.

Второй пример: несколько человек в одном бронировании

Форме бронирования поездки или мероприятия, которая собирает данные о нескольких путешественниках, выгодно определить пояс один раз для человека, заполняющего форму, и применить его как общее значение по умолчанию для всех путешественников, а не запрашивать его заново для каждого. Поле каждого путешественника остаётся редактируемым по отдельности, поскольку в групповом бронировании часто участвуют люди из другого пояса, чем тот, кто заполняет форму.

Возможность изменить значение

Выбор часового пояса существует именно потому, что определение по IP не всегда верно, особенно для посетителя, который использует VPN или путешествует. Всегда оставляйте поле редактируемым и сохраняйте то, что посетитель явно выбрал, вместо определённого значения по умолчанию, не определяя пояс заново и не перезаписывая его выбор при следующем визите.

Распространённая ошибка, которой стоит избегать

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

Определяйте один раз, а не при каждом визите

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

Если у вас уже есть конкретные координаты, а не IP-адрес, например адрес доставки, который ввёл посетитель, /v1/timezone определяет пояс напрямую по широте и долготе и может также принимать конкретную метку времени. Это полезно, когда нужно знать пояс, действовавший в определённый момент, а не прямо сейчас.

Сколько это стоит

Один запрос на каждый новый аккаунт или настройку предпочтений означает один запрос к API. Даже сервис, к которому каждый день стабильно приходят новые пользователи, при использовании только этой функции легко укладывается в 2 500 бесплатных запросов в день, которые входят в каждый ключ или доступны с одного адреса без ключа.

Правильный баланс для выбора часового пояса: определить разумное значение по умолчанию и дальше не мешать. Все поля описаны в документации по определению IPv4 и документации по определению часового пояса.