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

Сценарий:

Представьте, что клиент выполняет транзакцию, скажем, в 21:15 по местному времени в Рио, Бразилия (GMT-3), и он прыгает на рейс в Шанхай, Китай (GMT+8), ровно через 45 минут после этого. Технически транзакция была выполнена в 00:15 (UTC), верно? ДА!

В Китае та же транзакция произошла в 8:15 утра (GMT+8).

Информация о рейсе British Airways (Рио — Шанхай)

через Лондон согласно результатам поиска Google

[Отправление] 22:00 (Рио, Бразилия) — [Прибытие] 09:00 (Шанхай, Китай)

Несмотря на то, что полет длится 24 часа, разница с местным временем составляет всего 11 часов. Если мы хотим быть строгими и добавить 24 часа к местному времени Рио, то мы должны быть в Шанхае к 22:00 следующего дня, но когда вы выйдете из самолета, это будет 09:00 утра и солнце только начало подниматься.

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

Теперь, когда наш клиент находится в Китае в течение следующих 6 месяцев, какую дату/время, по вашему мнению, мы должны указать для транзакции?

Моя интуиция подсказывает, что вы всегда должны использовать местное время, в котором клиент просматривает транзакцию. Скорее всего, он проверит дату/время транзакции относительно местной даты/времени на своих часах или телефоне. Кроме того, уведомления, такие как 24 часа назад, будут точными независимо от того, куда он идет.

Теперь разница во времени меняется в основном по политическим причинам или каким-то могущественным мужским инстинктам, так как же вы можете написать код, защищающий от будущего?

Прелесть часовых поясов в том, что они хранят историю изменений смещения с течением времени, в то время как смещения дают вам только текущую разницу между местным временем и UTC.

И так?

Шанхай на момент написания этой статьи имеет смещение 8 часов. Это означает, что если в будущем смещение изменится, скажем, на 5 часов, то все предыдущие транзакции будут использовать новое смещение, которое технически неверно. Даже если даты были преобразованы из UTC, известного как Zulu (в военном деле), в местное время.

Используя часовой пояс, вы можете получить смещение, которое использовалось на момент совершения транзакции, и у вас будет правильное преобразование даты/времени как в прошлом, так и в будущем.

Вывод:

  • Сохраните дату/время в формате UTC (он же Zulu).
  • Представьте дату по местному времени, где она просматривается.
  • Используйте часовые пояса вместо смещений для большей точности (уважайте историю).
  • Сообщите пользователю о конкретном часовом поясе (местное время или GMT+3).

Лучше всего отображать дату/время как 15 января 1984 г., 16:00 (GMT +3).