Ми звикли, що в добі 24 години. Але двічі на рік це неправда: під час переходу на літній і на зимовий час один день триває 23 години, інший - 25. Одна година або повторюється двічі, або зникає зовсім. Дрібниця, через яку ламається на диво багато.
Що через це їде
- Логіка "минуло рівно 24 години" такого дня помиляється на годину.
- Завдання за розкладом, призначене на час усередині зниклої години, не запускається взагалі; призначене на повторювану годину - запускається двічі.
- Розрахунки "скільки відпрацьовано за добу", "кінець дня", "на скільки зсунути" - усе тихо їде вбік.
Це не теорія. На одному живому проєкті ми на такий зсув і налетіли - рівно на різниці між "24 годинами" і "однією календарною добою". Відтоді ставимося до часу з повагою.
Чому виручає UTC
UTC - це єдиний всесвітній годинник, у якого немає переходу на літній час. У UTC доба завжди рівно 24 години, година ніколи не повторюється і не зникає. Тому весь час усередині системи - у базі, у розрахунках, у порівняннях - ми зберігаємо і рахуємо в UTC. Там арифметика часу чесна і передбачувана.
Є і друга причина. Місцевий час - річ політична: країни змінюють правила переведення годинників, зсувають пояси, вводять і скасовують літній час. Якщо зберігати "10:00 за місцевим", через рік уже не можна точно сказати, якому світовому моменту це відповідало. UTC не змінюється ніколи - це надійна точка відліку, до якої завжди можна прив'язатися.
Часовий пояс - тільки на екрані
Користувачеві, звісно, потрібно бачити свій місцевий час, а не UTC. Тому переведення в часовий пояс ми робимо в найостанніший момент - під час виведення на екран. Усередині все живе в UTC, а "10:00 за Києвом" з'являється тільки там, де на час дивиться людина.
Зберігай і рахуй момент часу в UTC, переводь у часовий пояс тільки під час виведення. Тоді дивина з 23 і 25 годинами лишається на самому краю системи, де їй і місце.
Дрібниця, яка позбавляє цілого класу плаваючих багів "то на годину, то не в той день".
