В нашем последнем посте Часовые пояса — бельмо на боку мы говорили о некоторых сложностях и способах избежать проблем при установке часовых поясов в приложениях. Мы знаем, что это действительно важный вопрос, поэтому решили дать несколько дополнительных советов.
Запросы
Как мы упоминали ранее в разделе «Часовые пояса», это бельмо на нашей стороне, потому что Rails хранит даты в формате UTC, поэтому каждый запрос должен учитывать это. Но ActiveRecord будет аккуратно преобразовывать каждую полученную дату в формат UTC, поэтому нам не придется решать эту проблему.
Comment.where(“created_at >= :from AND created_at < :one_hour_after”, from: Time.current, one_hour_after: Time.current.advance(hours: 1))
Публикация по теме:Часовые пояса — заноза в боку
Локализация для каждого пользователя
Одно из наиболее распространенных применений приложения с несколькими часовыми поясами связано с тем, как данные, связанные со временем, отображаются для каждого конкретного пользователя. Если мы не хотим, чтобы пользователь был сбит с толку, мы ДОЛЖНЫ ежедневно показывать ему как даты, связанные с его собственными действиями, так и даты, связанные с действиями других пользователей в других регионах мира, в формате, понятном пользователю. Пользователя заботит только то, чтобы увидеть дату, иметь часы и знать, что данное действие было предпринято X минут назад, независимо от того, находится ли оно в UTC, EST или в любом другом часовом поясе.
Затем мы можем установить часовой пояс приложения только для данного конкретного запроса с часовым поясом, выбранным пользователем. Используя around_filter в ApplicationController или в конкретном ActionController, мы можем быть уверены, что даты будут рассчитаны с использованием часовой пояс пользователя.
around_filter :request_time_zone, :if => :current_user def request_time_zone(&block) Time.use_zone(current_user.time_zone, &block) end
Во-первых, для этого требуется, чтобы у пользователя был установлен часовой пояс. Затем мы можем либо вывести его каким-то образом, либо просто попросить пользователя установить его.
См. также:Асинхронная обработка с использованием SQS и Shoryuken
Если мы собираемся вывести это, давайте помнить, что хранить строку с местоположением пользователя (например, Америка/Аргентина/Буэнос_Айрес) — это не то же самое, что и разницу со временем UTC (например: -0300). Если часовой пояс пользователя изменяет время на один час назад или вперед для экономии энергии, мы можем сделать вывод об этом изменении, используя строку местоположения, но не используя значение разницы по сравнению с UTC, поскольку не каждая зона в этом часовом поясе произведет это изменение.
Мы можем использовать драгоценные камни, такие как этот, чтобы вывести текущий часовой пояс, сделав запрос к API геоимен (результат будет зависеть от отправленных координат).
TZinfo и TZinfo-данные
Важно понять, как Ruby знает, какое время в определенном часовом поясе было много лет назад, и было ли это летнее время или нет. Это можно проверить с помощью метода Time.current.dst? в Rails или с помощью другой подобной информации. В этом процессе tzinfo производит все расчеты в зависимости от исторических данных об изменениях в заданном часовом поясе. Эти данные можно извлечь из системы, на которой размещен сервер, или из tzinfo-data, драгоценного камня, который собирает всю эту информацию. Если мы не знаем, как часто хост сервера обновляет эту информацию или нет, может быть целесообразно приложить усилия для обновления базы данных tzinfo-data, работающей на сервере.
Тесты
Основная проблема с тестами заключается в том, что они разрабатываются и строятся в соответствии с часовым поясом машины, на которой они будут выполняться, поэтому оба часовых пояса совпадают. Вот почему эти ошибки могут быть обнаружены после развертывания в рабочей среде или, в лучшем случае, при их выполнении в Travis или на компьютере с часовым поясом, отличным от того, на котором работает, например, разработчик.
Жемчужиной, которая позволяет нам находить эти проблемы локально, является zonebie, который, в двух словах, случайным образом устанавливает часовой пояс перед запуском каждого теста. Но будьте осторожны, потому что даже если тесты работают правильно, это не обязательно означает, что проблема решена, так как может случиться так, что случайно выбранный часовой пояс не сгенерировал, например, изменение даты. Можно сказать, что чем чаще запускаются тесты, тем выше вероятность обнаружения этих ошибок.
Мы надеемся, что часовые пояса не станут для вас проблемой после прочтения этого поста! Помните, что есть еще один пост с советами по этой проблеме: Часовые пояса — это заноза в нашем боку.
Да ну, это просто, как, по-моему, чувак
Автор: Гастон Понти ([email protected])
