Даты в скриптах: где чаще всего ошибаются

Собираю статистику по ночным выгрузкам, складываю в папки по дате. Всё шло ровно до ночи перевода часов. Наутро обнаружила две папки за одно и то же число, а следующая ночь вообще пропала из отчёта.

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

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

Ваш случай с переводом часов лечится одной привычкой: внутри скрипта живёт только UTC. Локальное время появляется на самом последнем шаге, когда человек смотрит на экран.

Имена папок тоже берите из UTC. Тогда двух папок за одно утро не будет никогда.

А сравнение с датой из ответа сайта? Там приходит строка со смещением, каждый сайт пишет по-своему.

Разбирайте её в момент чтения и сразу приводите к UTC, дальше по коду ходит уже приведённое значение.

from datetime import datetime, timezone
from email.utils import parsedate_to_datetime

s = "Tue, 04 Mar 08:41:02 +0300" # из заголовка письма d = parsedate_to_datetime(s) # со смещением u = d.astimezone(timezone.utc) # к общему знаменателю print(u.isoformat()) ```

Правило простое: строка со смещением живёт ровно одну строчку кода. Дальше только приведённое.

Моё любимое место, где спотыкаются все по очереди: сравнение дат строками.

Пока формат ГГГГ-ММ-ДД, строки сравниваются правильно и сортируются правильно. Стоит появиться формату ДД.ММ.ГГГГ, и сортировка честно ставит третье марта раньше двадцать восьмого февраля, потому что она смотрит на первый символ. Ловится это не сразу, потому что месяц-другой данные могут ложиться удачно.

а isoformat это то же самое, что и такой порядок?

Да, там как раз год, месяц, день через дефис. Потому его и берут для имён файлов: сортировка по имени сразу даёт сортировку по времени.

Накину ещё три штуки, которые ловил руками.

Первое. Арифметика через «плюс восемьдесят шесть тысяч четыреста секунд». В сутках столько секунд бывает не всегда: перевод часов, високосная секунда. Прибавлять надо календарные сутки средствами библиотеки, а секунды оставить для замеров длительности.

Второе. Конец месяца. Классика это тридцать первое января плюс месяц. Библиотеки отвечают по-разному, кто-то даёт последний день февраля, кто-то ругается. Проверяйте, что именно делает ваша.

Третье. Границы суток при выборке. Когда пишете условие «за вчера», очень легко получить окно от полуночи до полуночи включительно с двух сторон и посчитать одну запись дважды. Нижняя граница включительно, верхняя строго меньше следующей полуночи, других вариантов не бывает.

плюсую про сутки в секундах, у меня на этом отчёт разъехался на час дважды за сезон

Ещё мелочь для тех, кто пишет на bash и таскает скрипты между машинами: date -d понимает человеческие фразы вроде yesterday далеко не везде. На макбуке коллеги тот же скрипт лёг сразу.

# работает и там, и там
python3 -c 'import datetime as d; print((d.datetime.now(d.timezone.utc).date()-d.timedelta(days=1)).isoformat())'

Некрасиво, зато одинаково себя ведёт.

Собрала итог по теме, чтобы не потерялось: время внутри только UTC, разбор чужой строки одной строчкой при чтении, формат с годом впереди для имён и сравнений, календарная арифметика библиотекой, границы суток слева включительно и справа строго.

Папки переделала, ночь перевода часов теперь проходит незаметно. Спасибо всем, кто накидал.