Проверка соответствия адреса указанному почтовому индексу до оформления заказа
Несовпадение почтового индекса и города в форме заказа выглядит мелкой опечаткой, пока не превращается в доставку совсем в другую часть страны.
Координация удалённой команды в разных часовых поясах
«UTC минус пять» это не часовой пояс, а смещение, и в большинстве стран, где переходят на летнее время, смещение меняется дважды в год. Именно поэтому удалённая команда из двенадцати человек месяцами назначала встречи правильно, а потом вдруг перестала, как раз около перевода часов, который никто из планировавших не догадался проверить.
Команда вела простую таблицу, в которой городу каждого сотрудника соответствовало фиксированное смещение относительно головного офиса, и обновляла её вручную, когда кто-нибудь вспоминал о скором переходе на летнее время. Таблица была неверна примерно полгода, в разные периоды по-разному, в зависимости от того, какие страны уже перевели часы, а какие нет, поскольку не все страны переходят на летнее время по одному графику, а некоторые не переходят вовсе.
Решением стала замена таблицы на запрос, который отражает реальные правила часовых поясов, а не снимок, который кто-то однажды ввёл вручную. Для города каждого сотрудника команда получала координату и отправляла её в /v1/timezone, который возвращает название часового пояса IANA для этой точки, например «America/Sao_Paulo» или «Asia/Kolkata», а не голое смещение. Это название несёт в себе реальные правила перехода на летнее время для конкретного региона, поэтому инструмент планирования, который хранит название IANA и вычисляет по нему текущее смещение, а не хранит смещение напрямую, автоматически остаётся точным при переводе часов: правила находятся в базе данных часовых поясов, а не в значении, которое кому-то нужно не забыть обновить.
Команда встроила это прямо в свой инструмент планирования встреч, так что при предложении времени встречи местное время каждого участника отображалось правильно и вычислялось заново в момент планирования, а не бралось из статичной таблицы. Для встреч, назначаемых за несколько недель, важна была и возможность эндпоинта вычислять смещение для конкретного момента в будущем: встрече, запланированной до перевода часов в каком-то регионе и проходящей после него, нужно было правильное смещение после перевода, а не то, что действовало в день планирования.
Заметным результатом стало меньше ошибок в расписании и меньше извиняющихся сообщений о встрече, выпавшей для кого-то на неподходящий час. Менее заметный результат: никому в команде больше не нужно было помнить графики перехода на летнее время в четырёх странах, а раньше это было чьей-то неформальной и неоплачиваемой обязанностью.
Такое решение одинаково легко масштабируется и вниз, и вверх. У команды из двенадцати человек и компании на тысячу сотрудников одна и та же проблема, просто в разных объёмах, и сам запрос в любом случае не становится сложнее, меняется только частота вызовов. Для небольшой команды использование легко укладывалось в бесплатную дневную квоту, которая входит в ключ, ведь определить часовые пояса дюжины человек несколько раз это ничтожная нагрузка по сравнению с 2 500 бесплатными запросами, доступными каждый день.
Ошибки часовых поясов обычно незаметны, пока не вызовут реальную проблему, а к тому времени ущерб уже нанесён: пропущенная встреча или сбитый с толку клиент. Однократное исправление источника данных устраняет весь этот класс ошибок в будущем. Документация по эндпоинту находится на странице /docs/timezone-lookup/.