Wierd behaviour when using .to on imaginary times

[laundmo]

Lets say i have a imaginary time, like 2022-03-27T02:30:00 in the Europe/Berlin timezone (due to DST change):

imagine = arrow.get(2022, 3, 27, 2, 30, tzinfo="Europe/Berlin")
assert imagine.imaginary == True

When i convert this to UTC and back, i get the following:

imagine.to("UTC").to("Europe/Berlin")
# <Arrow [2022-03-27T01:30:00+01:00]>

but when i shift the time back and forth a bit, i get a different result:

imagine.shift(seconds=+1).shift(seconds=-1)
# <Arrow [2022-03-27T03:30:00+02:00]>

imagine.shift(seconds=-1).shift(seconds=+1)
# <Arrow [2022-03-27T03:30:00+02:00]>

This is also inconsistent from pytz

import datetime
import pytz

berlin = pytz.timezone("Europe/Berlin")
utc = pytz.timezone("UTC")

imagine = datetime.datetime(2022, 3, 27, 2, 30, 0, 0, berlin)
utc_t = imagine.astimezone(utc)
back = utc_t.astimezone(berlin)

print(imagine) # 2022-03-27 02:30:00+00:53
print(utc_t) # 2022-03-27 01:37:00+00:00
print(back) # 2022-03-27 03:37:00+02:00

[agammann]

The starting wall time does not exist, so the UTC conversion and the imaginary-time adjustment can choose different valid replacements.

I reproduced your results with Arrow 1.2.3: the input carries +02:00, so converting it to UTC gives 00:30Z, which converts back to 01:30+01:00. shift() checks for imaginary times and resolves them forward across the gap, producing 03:30+02:00 instead.

If you want the forward adjustment explicitly, you can do it before converting:

import arrow
from dateutil import tz

imagine = arrow.get(2022, 3, 27, 2, 30, tzinfo='Europe/Berlin')
resolved = arrow.get(tz.resolve_imaginary(imagine.datetime))
print(resolved)
# 2022-03-27T03:30:00+02:00

I checked this on Arrow 1.2.3 and 1.4.0. In 1.4.0, the string timezone uses ZoneInfo, the imaginary input carries +01:00, and the UTC round-trip already returns 03:30+02:00. The explicit resolution above returns the same valid time in both versions. Dateutil documents the forward adjustment and the different behavior a UTC round-trip can have.

The pytz comparison has another issue: passing its timezone directly as tzinfo produces the historical +00:53 offset. With pytz, use berlin.localize(datetime.datetime(2022, 3, 27, 2, 30), is_dst=None); I checked that this raises NonExistentTimeError for this missing time.