Что это означает для всех библиотек преобразования времени и приложений, если DST будет списан в 2021 году?

Question

Так что ЕС думает о очистке от летнего времени и оставляет решение местному правительству принять решение остаться на зимнее или летнее время.

Что это означает для существующих библиотек кода и приложений, которые занимаются планированием, преобразованием часового пояса и т. Д.?

Пример,

Предположим, что в настоящее время зависит от летнего времени, время в моей стране может быть +8 UTC (лето) или +7 UTC (зима). После смены ЕС время моей страны постоянно +8 UTC.

Если у меня есть расписание для отправки мне электронного письма каждый день в 9:00:00 (по местному времени), я могу сохранить 9:00 в базе данных, затем отметьте

if(Date.utcNow().format(H:i:s, MY_TIMEZONE) == 09:00:00) sendEmail();

Будет ли этот код работать, независимо от лета или зимы после изменения ЕС?

В качестве альтернативы, если я храню в UTC 1:00:00 (+0), тогда

if(Date.utcNow().format(H:i:s, UTC) == 01:00:00) sendEmail(); // actually this will NOT send at the same local time everyday, because I expect it to send at summer or winter time depending on DST.

Будет ли этот код автоматически отправляться по новому местному времени летом навсегда после смены ЕС?

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

Answer 1

Это может не быть таким ужасным, как вы боитесь.

Существует нечто, называемое База данных часовых поясов IANA .И, как выясняется, многие языки и библиотеки уже используют эту базу данных, чтобы рассказать им о таких вещах, как смещения UTC и правила часового пояса.

А сама база данных IANA не являетсястатичный.Обновляется на удивление часто.И когда это происходит, те платформы, языки и библиотеки, которые зависят от него, как правило, также обновляются до более новой версии.Таким образом, программное обеспечение более высокого уровня просто продолжает работать, поскольку происходят изменения часового пояса.

В 2018 году база данных *1013* часового пояса IANA была обновлена ​​9 раз.Это примерно каждые 6 недель в среднем.Таким образом, изменения в правилах перехода на летнее время не являются ни редкими (в глобальном масштабе), ни катастрофическими.

Хотя самое худшее, что может произойти (и происходит с беспокоящей частотой), это то, что какое-то правительство, умирающее от разума, дает меньшеуведомление за неделю об изменении правил летнего времени.Кроме того, для этой части мира существует путаница в отношении текущего времени, пока все системы не будут иметь достаточно времени для обновления.

В случае с ЕС, похоже, что все продумано и спланировано хорошо вавансовый.Таким образом, База данных часовых поясов IANA и все системы, которые зависят от нее, смогут обновляться в течение длительного времени.

Если вам известен код, который программирует свое собственное правило перехода на летнее времялогика, вместо того, чтобы полагаться на хорошо поддерживаемую, обновляемую базу данных постоянно меняющихся правил часового пояса, тогда разумным решением было бы перенести ваш код из этой пользовательской логики как можно скорее.

Что касается частиНа ваш вопрос о том, как хранить время для регулярно запланированных событий, лучше всего хранить отметку времени в точности так, как это намеревается сделать человек.Например, если вы ожидаете, что что-то произойдет в 9:00 по местному времени, то это должно быть запрограммировано на 9:00 по местному времени.Если вы ожидаете, что что-то произойдет в одно и то же время в глобальном масштабе, вероятно, его следует запрограммировать на UTC.

Дополнительные советы по передовым методам в этой области см. В этом SO ответе .

Обновление

Мэтт Джонсон напоминает нам о замечательной статье, которую он написал несколько лет назад, в которой содержатся полезные советы для правительств с мертвыми мозгами.Если они когда-либо научатся читать, это первое, что они должны прочитать: https://codeofmatt.com/on-the-timing-of-time-zone-changes/