Bugs item #1553577, was opened at 2006-09-06 11:11 Message generated for change (Comment added) made by nnorwitz 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: 3rd Party >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Skip Montanaro (montanaro) >Assigned to: Neal Norwitz (nnorwitz) 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: Neal Norwitz (nnorwitz) Date: 2006-09-08 19:08 Message: 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. ---------------------------------------------------------------------- Comment By: Stuart Bishop (zenzen) Date: 2006-09-07 21:36 Message: 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 ---------------------------------------------------------------------- Comment By: Tim Peters (tim_one) Date: 2006-09-07 10: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 00: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
