CODEWITHSUNDEEP
pythondatetimetimezone
zap
zap

Reputation: 700

Inconsistencies in Time Arithmetic with Timezone-Aware DateTime Objects in Python

Surprisingly, time arithmetic is not handled as expected with pythons timezone aware objects. For example consider this snippet that creates a timezone aware object at 2022-10-30 02:00.

from datetime import datetime, timezone, timedelta
from zoneinfo import ZoneInfo


zone = ZoneInfo("Europe/Madrid")

HOUR = timedelta(hours=1)

u0 = datetime(2022, 10, 30, 2, tzinfo=zone)

At 2:59 the clocks shifted back to 2:00, marking the ending of the daylight saving time period. This makes 2022-10-30 02:00 ambiguous. In 2022-10-30 the clocks showed 2:00 twice. Fist comes the DST instance 2022-10-30 02:00:00+02:00 followed by the winter time instance 2022-10-30 02:00:00+01:00, when the timezone shifted from CEST to CET. Python solves the ambiguity by selecting u0 to be the first of the two instances, the one within the DST interval. This is verified by by printing out u0 and its timezone name:

>>> print(u0)
2022-10-30 02:00:00+02:00
>>> u0.tzname()
'CEST'

which is the central European daylight saving timezone.

If we add one hour to u0, the passage to CET, i.e. the winter timezone for central Europe, is correctly detected.

>>> u1 = u0 + HOUR
>>> u1.tzname()
'CET'

However, the time does not fold back to 2:00, as expected:

>>> print(u1)
2022-10-30 03:00:00+01:00
'CET'

So, with the addition of a 1h interval, it looks as if 2 hours have passed. One hour due to the wall time shifting from 2:00 to 3:00 and another one due to the change of the timezone that is shifted 1h towards UTC. Conversely one would expect u1 to print out as 2022-10-30 02:00:00+01:00. This 2 hour shift is verified by converting u0 and u1 to UTC:

>>> u0.astimezone(timezone.utc)
datetime.datetime(2022, 10, 30, 0, 0, tzinfo=datetime.timezone.utc)
>>> u1.astimezone(timezone.utc)
datetime.datetime(2022, 10, 30, 2, 0, tzinfo=datetime.timezone.utc)

To make things worse, the time interval between u1 and u0 is inconsistently calculated depending on the chosen timezone. On the one hand we have:

>>> u1 - u0
datetime.timedelta(seconds=3600)

which is equivalent to a 1h interval. On the other hand, if we do the same calculation in UTC:

>>> u1.astimezone(timezone.utc) - u0.astimezone(timezone.utc)
datetime.timedelta(seconds=7200)

the calculated interval is 2h.

In conclusion, it appears that Python's handling of timedelta in timezone-aware datetimes emphasizes local clock times rather than consistent logical intervals, leading to potential discrepancies when crossing DST boundaries.

In my opinion, this can be misleading, as the existence of the zoneinfo library gives the impression that these kind of problems have been solved.

Does anyone know if this is a bug or expected behaviour? Has anyone else encountered this issue, and how do you manage these discrepancies in your applications? If this is expected behavior, perhaps Python documentation should provide clearer guidance or warnings about performing time arithmetic with timezone-aware objects.

Edit

I have verified the described behavior with python 3.11 and 3.12. Similar results are obtained for other time zones, e.g. "Europe/Athens", but I have not performed an extensive check for all time zones.

Upvotes: 5

Views: 166

Answers (1)

FObersteiner
FObersteiner

Reputation: 25684

In addition to my comment, here's an example using fold to maybe help clarify things (note the slightly modified time):

from datetime import datetime, timezone, timedelta
from zoneinfo import ZoneInfo

zone = ZoneInfo("Europe/Madrid")
HOUR = timedelta(hours=1)
u0 = datetime(2022, 10, 30, 1, 59, 59, tzinfo=zone)

print(u0+HOUR) # one hour later on a *wall clock*...
2022-10-30 02:59:59+02:00 # CEST

print((u0+HOUR).replace(fold=1)) # specify on which side of the "DST fold" we want to be...
2022-10-30 02:59:59+01:00 # CET

You can use fold to specify if the datetime should fall on a specific side of the DST "fold".

Applying Python's timedelta arithmetic, wall time still doesn't care:

print((u0+HOUR).replace(fold=1)-u0)
1:00:00

print((u0+HOUR)-u0)
1:00:00

So if you want timedelta arithmetic to be absolute time arithmetic, use UTC (as shown in the OP).

Where things get really weird is DST gaps (non-existent datetimes):

u0 = datetime(2022, 3, 27, 1, 59, 59, tzinfo=zone)

print(u0+timedelta(seconds=1))
2022-03-27 02:00:00+01:00 # non-existent datetime; should be 03:00 CEST

Again, to circumvent such oddities: Use absolute add in UTC;

print((u0.astimezone(timezone.utc)+timedelta(seconds=1)).astimezone(zone))
2022-03-27 03:00:00+02:00

The dst tag wiki has more details and illustrations of DST gaps and folds.

Upvotes: 1

Related Questions