Переход на летнее время влияет на результат сохранения и загрузки файла icalendar?
У меня есть несколько модульных тестов, которые начали давать сбой сегодня после перехода на летнее время.
Мы используем модуль Python iCalendar для загрузки и сохранения файлов ics.
Следующий скрипт представляет собой упрощенную версию нашего теста. Скрипт отлично работает летом и не работает зимой, по состоянию на сегодняшнее утро. Неисправность можно воспроизвести, переведя часы назад вручную. Вот результат скрипта:
[root@ana icalendar]# date 10250855
Sat Oct 25 08:55:00 CEST 2008
[root@ana icalendar]# python dst.py
DTSTART should represent datetime.datetime(2015, 4, 4, 8, 0, tzinfo=tzfile('/usr/share/zoneinfo/Europe/Brussels')) Brussels time
DTSTART should represent datetime.datetime(2015, 4, 4, 6, 0, tzinfo=<icalendar.prop.UTC object at 0x956b5cc>) UTC
DTSTART represents datetime.datetime(2015, 4, 4, 6, 0, tzinfo=<icalendar.prop.UTC object at 0x956b5cc>) Brussels time
[root@ana icalendar]# date 10260855
Sun Oct 26 08:55:00 CET 2008
[root@ana icalendar]# python dst.py
DTSTART should represent datetime.datetime(2015, 4, 4, 8, 0, tzinfo=tzfile('/usr/share/zoneinfo/Europe/Brussels')) Brussels time
DTSTART should represent datetime.datetime(2015, 4, 4, 6, 0, tzinfo=<icalendar.prop.UTC object at 0x96615cc>) UTC
DTSTART represents datetime.datetime(2015, 4, 4, 7, 0, tzinfo=<icalendar.prop.UTC object at 0x96615cc>) Brussels time
Traceback (most recent call last):
File "dst.py", line 58, in <module>
start.dt, startUTCExpected)
AssertionError: calendar's datetime.datetime(2015, 4, 4, 7, 0, tzinfo=<icalendar.prop.UTC object at 0x96615cc>) != expected datetime.datetime(2015, 4, 4, 6, 0, tzinfo=<icalendar.prop.UTC object at 0x96615cc>)
А вот и весь сценарий.
Итак, вопросы: - почему мое текущее время (и в какой части летнего времени я нахожусь) влияет на загрузку / сохранение / анализ временных меток? Я ожидал, что этого не произойдет. - как бы вы провели модульное тестирование такого рода ошибок, если это ошибка? Очевидно, я не хочу, чтобы мои модульные тесты сбрасывали часы на моем компьютере.
Ссылка на весь ваш скрипт не работает.
Ответы 1
Не глядя на ваш код (и процитированный тестовый сценарий, мой мозг не может понять прямо сейчас) Я заметил, что вы пытаетесь получить время, которое находится в другом часовом поясе, чем тот, в котором вы находитесь. (Думайте о DST как о другом TIMEZONE, а не о + -1 час от текущего часового пояса). Это может (в зависимости от того, как вы это делаете) привести к увеличению или уменьшению количества часов. (Например, когда вы летите, вы начинаете в один момент и добираетесь до своего местоположения до того, как вы начали, все в местном времени)
Я видел такие проблемы с Unit Test и Timezone / TZ + DST почти за 8 лет. Мне действительно любопытно ответить на этот вопрос в более общем виде (как подготовиться к надежному модульному тестированию изменений DST).