Title: zoneinfo: wrong time difference across transition when tzinfo is equal
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.9
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: d.grellscheid, p-ganssle
Priority: normal Keywords:

Created on 2020-10-13 09:01 by d.grellscheid, last changed 2020-10-21 18:59 by p-ganssle. This issue is now closed.

File name Uploaded Description Edit d.grellscheid, 2020-10-13 09:01 d.grellscheid, 2020-10-13 09:32 d.grellscheid, 2020-10-13 09:41
Messages (5)
msg378545 - (view) Author: David Grellscheid (d.grellscheid) * Date: 2020-10-13 09:01
I'm comparing two aware timestamps during a clock transition that differ only in their fold= value.

When taking the difference of two aware timestamps with the *same* tzinfo, the fold parameter is ignored. 

A difference between two timestamps with different tzinfo works correctly, with fold taken into account.

For the attached code I would expect all timedeltas to be the same, but I get:

0:00:00 Oslo_1   - Oslo_0
1:00:00 Berlin_1 - Oslo_0
1:00:00 Oslo_1   - Berlin_0
0:00:00 Berlin_1 - Berlin_0
msg378548 - (view) Author: David Grellscheid (d.grellscheid) * Date: 2020-10-13 09:32
To make it clear that this issue is not covered by ...

"Two such instances that differ only by the value of the fold attribute will not be distinguishable by any means other than an explicit access to the fold value." (PEP 495)

I have modified the timestamps by one minute, so that they differ in more than just the fold attribute.

All these should be 1:01:00 apart
0:01:00 Oslo_1   - Oslo_0
1:01:00 Berlin_1 - Oslo_0
1:01:00 Oslo_1   - Berlin_0
0:01:00 Berlin_1 - Berlin_0
msg378549 - (view) Author: David Grellscheid (d.grellscheid) * Date: 2020-10-13 09:41
Here's a third example, without fold= involved. The spring transition also does not work when the timezone in the difference is equal:

01:59:00 to 03:01:00 should be 2 minutes

All these should be 0:02:00 apart
1:02:00 Oslo_1   - Oslo_0
0:02:00 Berlin_1 - Oslo_0
0:02:00 Oslo_1   - Berlin_0
1:02:00 Berlin_1 - Berlin_0
msg378554 - (view) Author: David Grellscheid (d.grellscheid) * Date: 2020-10-13 11:22
OK, having read, this bizarreness is actually intended behaviour. It goes completely against my intuitive understanding of how this should come out. No additions are involved, just subtractions and equalities.

Can we get some big warning boxes in the documentation about this? :)
msg379235 - (view) Author: Paul Ganssle (p-ganssle) * (Python committer) Date: 2020-10-21 18:59
Yeah, people are very confused by this, which is why I wrote that article.

Maybe there is a place for big warnings somewhere? I have been mulling over the possibility of proposing a backwards-incompatible (though minimally so, hopefully) change to arithmetic semantics that would work well with how people think this should work, but I think any such backwards-incompatible change would be a Big Dealâ„¢, and unfortunately quite hard to warn about with a proper deprecation period.
Date User Action Args
2020-10-21 18:59:20p-gansslesetstatus: open -> closed
type: behavior
messages: + msg379235

resolution: not a bug
stage: resolved
2020-10-13 11:22:12d.grellscheidsetmessages: + msg378554
2020-10-13 10:24:21xtreaksetnosy: + p-ganssle
2020-10-13 09:41:21d.grellscheidsetfiles: +

messages: + msg378549
title: zoneinfo: fold not taken into account in time difference when tzinfo is equal -> zoneinfo: wrong time difference across transition when tzinfo is equal
2020-10-13 09:32:30d.grellscheidsetfiles: +

messages: + msg378548
2020-10-13 09:01:16d.grellscheidcreate