Daylight savings time change affecting the outcome of saving and loading an icalendar file ?

Question

I have some unit tests that started failing today after a switch in daylight savings time.

We're using the iCalendar python module to load and save ics files.

The following script is a simplified version of our test. The script works fine in 'summer' and fails in 'winter', as of this morning. The failure can be reproduced by setting the clock back manually. Here's the output of the script:

[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>)

And here is the whole script.

So, questions: - why would my current time (and which part of DST I'm in) affect the loading/saving/parsing of timestamps ? I would expect it not to. - how would you unit test this kind of bug, if it is a bug ? Obviously, I don't want my unit tests to reset the clock on my computer.

Answer 1

Without looking at your code (and the quoted test-run-script my brain fails to understand right now) I notice that you try to get a time that is in a different timezone than the one you are at. (Think of DST as a another TIMEZONE instead of +-1 hour from current timezone). This could (depending on how you do it) lead to a gain or loss of hours. (Like when your flying, you start at one time and getting to your location before you started, all in local time)