When using the pytz package (http://pytz.sf.net/) to create
timezone info objects datetime.datetime.now() behaves
differently than the regular datetime.datetime()
contstructor.  Here's an example:

    >>> import pytz
    >>> info = pytz.timezone("US/Central")
    >>> info
    <DstTzInfo 'US/Central' CST-1 day, 18:00:00 STD>
    >>> import datetime
    >>> now = datetime.datetime.now(tz=info)
    >>> now
    datetime.datetime(2006, 9, 6, 12, 44, 18, 983849,
tzinfo=<DstTzInfo 'US/Central' CDT-1 day, 19:00:00 DST>)
    >>> t2 = datetime.datetime(2006, 9, 6, 12, 44, 18,
983849, tzinfo=info)
    >>> t2
    datetime.datetime(2006, 9, 6, 12, 44, 18, 983849,
tzinfo=<DstTzInfo 'US/Central' CST-1 day, 18:00:00 STD>)
    >>> now.tzinfo == info
    False
    >>> t2.tzinfo == info
    True

It appears that datetime.datetime.now() makes an
off-by-one-hour copy of the timezone info it was passed.
I've reproduced this on 2.4.3 and 2.5c1 as of August 17.

(It's also a little annoying that the timezone arg for
datetime.datetime.now() is "tz" while the timezone arg for
datetime.datetime() is "tzinfo".  Is there a good
reason for
them to be different?)

Skip

Logged In: YES 
user_id=33168

Since Tim wrote this code AFAIK, there *had* to be a good
reason. :-)

Logged In: YES 
user_id=31435

`tzinfo` is the name of a datetime data attribute, and the
same name (i.e., "tzinfo") is generally used for arguments
that mindlessly attach a subclass of the `tzinfo` class to
an object as the value of its `tzinfo` data attribute.  The
datetime constructor is an example of that.  `tz` is
generally used when the time zone info is /actively
applied/, as now() does.

In contrast, the datetime constructor never makes any
attempt at conversion; if a tzinfo argument is passed, it's
merely tacked on to the datetime object.

Beyond that, I have no idea why the pytz class passed to
now() isn't showing up as the resulting datetime object's
tzinfo member.  For example, that's not what happens if you
try this in the Python sandbox "datetime" directory:

>>> from US import Eastern
>>> from datetime import datetime
>>> now = datetime.now(Eastern)
>>> now
datetime.datetime(2006, 9, 7, 12, 49, 48, 430000,
tzinfo=<US.USTimeZone object at 0x009E89B0>)
>>> t2 = datetime(2006, 9, 7, 12, 49, 48, 430000,
tzinfo=Eastern)
>>> t2
datetime.datetime(2006, 9, 7, 12, 49, 48, 430000,
tzinfo=<US.USTimeZone object at 0x009E89B0>)
>>> now.tzinfo == Eastern
True
>>> t2.tzinfo == Eastern
True
>>> t2.tzinfo is now.tzinfo is Eastern
True

I expect the pytz developers could shed light on that. 
datetime.now(tz) with `tz` not None first mindlessly
constructs a datetime object (let's call it `self`) based on
current (UTC) time with tz attached as the value of its
`tzinfo` data attribute, and then returns the result of invoking

tz.fromutc(self)

So if pytz overrides the default `fromutc()` implementation
in its tzinfo subclasses, you'll get back whatever they
decided to return from it.  No code in Python "makes an
off-by-one-hour copy" here.

In short, I believe your primary question here is about how
pytz works, and I can't answer that.  IIRC, pytz does fancy
stuff trying to avoid the 1-hour ambiguities at DST
transition times, and I wouldn't be surprised if, toward
that end, they have multiple internal tzinfo subclasses for
each "conceptual" time zone.

Logged In: YES 
user_id=46639

This is a pytz issue, and a result of me abusing Tim's code
in ways he never intended. Tim is quite correct in that
there are actually several tzinfo instances under the
covers. In order to to unambiguous localtime calculations,
an extra bit of information needs to be known (the is_dst
flag in most datetime libraries). pytz uses the tzinfo
instance to store this bit of information. The side affects
of doing this are the behavior you noticed, and confusion as
constructing datetime instances needs to be done as per
pytz's README rather than the documented method in the
Python Library Reference.

>>> import pytz
>>> info = pytz.timezone('US/Central')
>>> info
<DstTzInfo 'US/Central' CST-1 day, 18:00:00 STD>
>>> from datetime import datetime
>>> now = info.localize(datetime.now(), is_dst=True)
>>> now
datetime.datetime(2006, 9, 8, 11, 19, 29, 587943,
tzinfo=<DstTzInfo 'US/Central' CDT-1 day, 19:00:00 DST>)
>>> t2 = info.localize(datetime(2006, 9, 8, 11, 19, 29, 587943))
>>> t2
datetime.datetime(2006, 9, 8, 11, 19, 29, 587943,
tzinfo=<DstTzInfo 'US/Central' CDT-1 day, 19:00:00 DST>)
>>> now.tzinfo == info
False
>>> t2.tzinfo == info
False
>>> now.tzinfo == t2.tzinfo
True

Last time I tried, it seemed impossible to support both
pytz's goals and the datetime construction API specified in
the Python Library Reference without extending the Python
datetime module (and I have yet to specify what would be
required).

If I was to add an __eq__ method to the tzinfo classes, I'm
not actually sure what the correct behavior should be.
Should US/Eastern Daylight Savings Time really equate to
US/Eastern Standard Time? Should US/Eastern Daylight Savings
Time in 2002 really equate to US/Eastern Daylight Savings
Time in 2007? The umbrella timezone might be the same, but
the UTC offsets or switchover dates are different.

The pytz bugtracker is at 
https://launchpad.net/products/pytz/+bugs

Logged In: YES 
user_id=33168

Based on Stuart's comment, I'm closing this.  Skip, if
there's any part of this that you think is a bug, re-open
this with a comment about the precise issue or open a new
bug report.  Thanks.