Datetime Daylight savings transition problem [Python]

Question

I get the following error for my timestamp field when converting from UTC to CET due to the transition to daylight savings last Saturday/Sunday:

AmbiguousTimeError: Cannot infer dst time from 2020-07-31 11:17:18+00:00, try using the 'ambiguous' argument

#converting timestamp fields to CET (Europe,Berlin)

df['timestamp_berlin_time'] = df['timestamp'].dt.tz_localize('Europe/Berlin')

I tried the following snippet:

df['timestamp_berlin_time'] = df['timestamp'].dt.tz_localize('CET',ambiguous='infer')

but this gives me then this error:

AmbiguousTimeError: 2020-07-31 11:17:18+00:00

Data sample:

0  2020-07-31 11:17:18+00:00
1  2020-07-31 11:17:18+00:00
2  2020-08-31 16:26:42+00:00
3  2020-10-20 07:28:46+00:00
4  2020-10-01 22:11:33+00:00

Name: timestamp, dtype: datetime64[ns, UTC]

Answer 1

If your input is UTC but UTC isn't set yet, you can localize to UTC first, here eg:

df['timestamp'] = df['timestamp'].dt.tz_localize('UTC')

If your input already is converted to UTC, you can simply tz_convert , eg:

s = pd.Series(pd.to_datetime(['2020-10-25 00:40:03.925000', 
                              '2020-10-25 01:40:03.925000', 
                              '2020-10-25 02:40:03.925000'], utc=True))

s.dt.tz_convert('Europe/Berlin')
# 0   2020-10-25 02:40:03.925000+02:00
# 1   2020-10-25 02:40:03.925000+01:00
# 2   2020-10-25 03:40:03.925000+01:00
# dtype: datetime64[ns, Europe/Berlin]

If your input timestamps represent local time (here: Europe/Berlin time zone), you can try to infer the DST transition based on order:

s = pd.Series(pd.to_datetime(['2020-10-25 02:40:03.925000', 
                              '2020-10-25 02:40:03.925000', 
                              '2020-10-25 03:40:03.925000']))

s.dt.tz_localize('Europe/Berlin', ambiguous='infer')
# 0   2020-10-25 02:40:03.925000+02:00
# 1   2020-10-25 02:40:03.925000+01:00
# 2   2020-10-25 03:40:03.925000+01:00
# dtype: datetime64[ns, Europe/Berlin]

Note: CET is not a time zone in a geographical sense. pytz can handle some of these for historical reasons but don't count on it. In any case, it might give you static tz offsets - which is not what you want if you expect it to include DST transitions.