Hi,

the shift() method is nice and seems to work with localized time with some kind of "natural" semantic. However it leads to some results (related to differences between time points).

>>> t0 = arrow.now().shift(weeks=3)    # The day before the next DST fall transition

>>> t0
<Arrow [2019-10-26T16:33:24.883042+02:00]>

>>> t1 = t0.shift(days=1)

>>> t1
<Arrow [2019-10-27T16:33:24.883042+01:00]>

>>> t1 - t0
datetime.timedelta(1)

So far, so good. A DST transition occurs between t0 and t1 (I'm living in Paris) and shifting by one day keeps the same time (16:33) with UTC offset adjusted (+02:00 to +01:00). The difference is one day, expressed as a timedelta.

Now, convert the dates into UTC:

>>> t2 = t0.to('UTC')

>>> t2
<Arrow [2019-10-26T14:33:24.883042+00:00]>

>>> t3 = t1.to('UTC')

>>> t3
<Arrow [2019-10-27T15:33:24.883042+00:00]>

>>> t2 == t0 and t3 == t1
True

>>> t1 - t2
datetime.timedelta(1, 3600)

>>> (t3 - t2) == (t1 - t0)
False

>>> t0 + (t3 - t2) == t1
False

The problem is that, while the time points are the same in local time or UTC (which is expected), their difference is no longer the same. And a few expected invariants are no longer true.

As a conclusion,

1. Differences between time points shall always imply a conversion to UTC, even if they are in the same time zone. At least, we would have t1 - t0 == t3 - t2 == t3 - t0 == t1 - t2. This should be clearly explained in the documentation.
2. The documentation should explain that a difference between 2 time points lead to a "naive" delta, even if arrow enforces time zone aware time points.
3. Time zone aware time delta could be introduced with a clean semantic (to be defined?)...

Best regards,

Antoine