incorrect time difference for times before and after DST switch about arrow

[Eric-Jiang1]

Hi! I'm interested in working on this bug.

[bschick]

If this gets addressed, it would also make sense to change the shift function to account for DST changes. Its hard to say which approach is 'correct', but I think accounting for DST is more natural and would result in fewer errors in code that uses arrow. The current shift behavior ignores DST change on the resulting time:

>>> t1=arrow.get(datetime(2023, 3, 11, 21), 'US/Pacific')
>>> t1
<Arrow [2023-03-11T21:00:00-08:00]>
>>> t2=t1.shift(hours=12)
>>> t2
<Arrow [2023-03-12T09:00:00-07:00]>

Since t1 is not DST and t2 is within DST (clock has move forward), adding 12 hours to t1 would result in a wall-clock time that is 13 hours ahead. Meaning t2 would be <Arrow [2023-03-12T10:00:00-07:00]>

Either approach might confuse someone, but given that a reason to use arrow is timezone awareness (and a big part of most timezones is DST) I'd prefer both DST aware math operations and more DST aware shift.