Bugs item #1553577, was opened at 2006-09-06 14:11 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553577&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Nobody/Anonymous (nobody) Summary: datetime.datetime.now() mangles tzinfo Initial Comment: 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 ---------------------------------------------------------------------- >Comment By: Tim Peters (tim_one) Date: 2006-09-07 13:11 Message: 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. ---------------------------------------------------------------------- Comment By: Neal Norwitz (nnorwitz) Date: 2006-09-07 03:08 Message: Logged In: YES user_id=33168 Since Tim wrote this code AFAIK, there *had* to be a good reason. :-) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1553577&group_id=5470 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
