Перевод времени с точки зрения ИТ-шника

Уже давно идут споры о пользе/вреде летнего времени, хорошо это или плохо, и всё такое. На основных доводах я заострять внимания не буду (хотя и на мой взгляд, смысла особого в наличие перехода нет, а вред уж точно есть). Я хочу немного рассказать о том, какие косяки от этого лезут у программистов, ибо с каждым годом, это всё более актуальнее.

Начнём с простого, время бывает UTC и локальное (если не вдаваться в подробности с атомным временем, и всякими календарями). У UTC есть замечательное свойство: оно течёт постоянно и у всех одно и тоже. Т.е. что у программиста в Америке, что у сурового челябинского админа — цифры одни и те же. Соответственно, по возможности хранить время нужно именно в UTC и использовать при внутренних расчётах именно его, конвертируя его для пользователя при выводе на экран. Но на практике, это оказывается не очень удобным, из-за того, что на всех слоях время необходимо конвертировать, в одну или другую сторону, что может привести к страшной путаницы в самом коде и лишним преобразованиям. При этом для локальных программ, вроде бы это всё не страшно, поэтому UTC можно и не использовать, а в результате получаются разные забавные ситуации:
Как-то работали мы с американским заказчиком, во время очередного билда мы закидывали свежую базу с начальными данными. И всё было хорошо, кроме того что всё падало.  Проблема оказалась в том, что сгенерированные данные были в "будущем", и в результате они не находились по фильтру с getdate(). Естественно через 9 часов всё начинало замечательно работать.


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

Теперь, собственно о переходе на летнее время. Предположим, что у нас есть система мониторинга, которая смотрит живучесть системы раз в минуту, и если она не откликается поднимает тревогу, рестартит приложение, носится с воплями и кричит о том, что всё пропало.
28 марта в 2 часа ночи мгновенно становится 3 часа ночи и по факту система уже не отвечала целый час (!!!) Как результат получим epic fail приложения.

Другой пример: у нас пишутся логи с данными. В последствии мы хотим по ним построить отчёт. Логи длинные, идут годами. Как результат: пишем в UTC, можем получить сдвиг на час в отчёте UTC + Offset который в течение года разный. Пишем в локальном времени: получаем дырку в летнем времени и двойные данные в зимнем (что ещё хуже, если требовать уникальность). В любом случае, ничего хорошего.

Ну и для полноты картины, третий пример, который связан уже с обратным переходом. Представьте себе небольшое кеширование, данные обновляются раз в минуту, в остальных случаях мы просто возвращаем кешированное значение. Когда мы получим два раза по 2 часа ночи, мы в течение целого часа будем сидеть в кеше: надо обновляться когда текущее время больше чем  2:59 + 1, а сейчас опять 2:00. В общем всё просто замечательно выходит. 

А теперь представьте, что делать с системами управления ЖД и авиа-транспортом, когда резко поезда с самолётами начинают опаздывать, а вылета в 2:30 в эту ночь не будет. Представьте, сколько может стоить подобная ошибка со временем в программе?

Так что моё мнение, сугубо со стороны программиста: переход на летнее время может повлечь непредсказуемое поведение программы с такими же последствиями. И что самое интересное, а вот фиг это оттестируешь заранее, просто и не вспомнишь об этом.