pytz: Why do these different methods give different UTC offsets?

When creating a datetime object in a specific time zone using pytz I get a different UTC offset depending on whether I use datetime.datetime() or datetime.datetime.now().

now() seems to give the correct UTC offset for the time zone, datetime() gives an offset that I don't recognise.

Why are they different? What is the significance of the offset that datetime() assigns?

Here's my code:

import datetime
import pytz

la_paz = pytz.timezone('America/La_Paz')

a = datetime.datetime.now(la_paz)
print a, a.utcoffset()

# 2011-03-22 05:30:13-04:00 -1 day,开发者_开发问答 20:00:00
# -4 hours is the correct UTC offset for La Paz

b = datetime.datetime(2011, 03, 22, 5, 30, tzinfo=la_paz)
print b, b.utcoffset()

# 2011-03-22 05:30:00-04:33 -1 day, 19:27:00
# What is the significance of -4:33?

It seems that datetime() will use the first recorded timezone for the region by default, and in many cases (like in La Paz) this is old and no longer valid.

The datetime must instead be created naive and then localised like so:

b = la_paz.localize(datetime.datetime(2011, 03, 22, 5, 30))
print b, b.utcoffset()

now() appears to do the localization automatically.

From the pytz documentation:

This library only supports two ways of building a localized time. The first is to use the localize() method provided by the pytz library. This is used to localize a naive datetime (datetime with no timezone information):

>>> loc_dt = eastern.localize(datetime(2002, 10, 27, 6, 0, 0))
>>> print loc_dt.strftime(fmt)
2002-10-27 06:00:00 EST-0500

The second way of building a localized time is by converting an existing localized time using the standard astimezone() method:

>>> ams_dt = loc_dt.astimezone(amsterdam)
>>> ams_dt.strftime(fmt)
'2002-10-27 12:00:00 CET+0100'

Or put another way:

b = datetime.datetime(2011, 03, 22, 5, 30, tzinfo=la_paz)

Is not supported by pytz