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

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

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

OK, having read https://blog.ganssle.io/articles/2018/02/aware-datetime-arithmetic.html, 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? :)

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.