Difference between datetime.combine() and pytz.localize()

Question

I am a bit puzzled by the following behavior. Suppose I use datetime.combine() to construct a timezone-aware object:

>>> date
datetime.date(2018, 10, 17)
>>> time
datetime.time(6, 0)
>>> tz
<DstTzInfo 'Europe/Berlin' LMT+0:53:00 STD>
>>> datetime.combine(date, time, tzinfo=tz)
datetime.datetime(2018, 10, 17, 6, 0, tzinfo=<DstTzInfo 'Europe/Berlin' LMT+0:53:00 STD>)

or I use pytz.localize() to do the same:

>>> tz.localize(datetime.combine(date, time))
datetime.datetime(2018, 10, 17, 6, 0, tzinfo=<DstTzInfo 'Europe/Berlin' CEST+2:00:00 DST>)

Note how the tzinfo’s timezone name and offset have changed. I am unable to find a proper documentation for that behavior. The pytz documentation says

Unfortunately using the tzinfo argument of the standard datetime constructors “does not work” with pytz for many timezones.

So what exactly is going on here? (Somewhat related questions are here or here.)

Answer 1

You just found out (again) that you should never directly add timezone information when creating timezone-aware datetimes. Always use tz.localize().

The problem you are seeing is because datetime.combine doesn't adjust the tzinfo object to the actual datetime. It still assumes the timezone information of the first valid date in this timezone, which was in the late 1800's and happened to be 0:53:00 off from UTC.