Patches item #1457227, was opened at 2006-03-23 22:06 Message generated for change (Comment added) made by davidfraser You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457227&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: Modules Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Chris AtLee (catlee) Assigned to: Nobody/Anonymous (nobody) Summary: timestamp() method for datetime objects Initial Comment: This patch adds a timestamp() method to datetime objects. It is equivalent to: time.mktime(self.timetuple()) I pulled out the dstflag calculation code from datetime_timetuple into a new function, get_dstflag, so that datetime_timestamp can make use of the same code. The patch also includes updates to the datetime documentation, and a simple unit test. ---------------------------------------------------------------------- Comment By: David Fraser (davidfraser) Date: 2006-09-16 21:43 Message: Logged In: YES user_id=221678 I know this is closed... I think it would be helpful to either 1) add a description to the documentation of how to convert back, explaining the timezone story 2) add a timestamp() function that takes a timezone parameter ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-23 23:41 Message: Logged In: YES user_id=6380 Well, that they both exist implies that the linkage is ambiguous... I think it's just not worth the new API given that it's (as you admit) just a shorthand for two other calls. There's also the problem that the range for timestamps is much smaller than the range of datetime -- this isn't a problem for .[utc]fromtimestamp() but is a problem for the reverse API. ---------------------------------------------------------------------- Comment By: Chris AtLee (catlee) Date: 2006-03-23 23:37 Message: Logged In: YES user_id=186532 The .fromtimestamp and .utcfromtimestamp class methods already imply this linkage, don't they? What if timestamp() only works if the datetime object isn't "naive"? ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2006-03-23 22:23 Message: Logged In: YES user_id=6380 I'm against this functionality. It suggests an linkage between the "naive" (timezone-unaware) time carried in the datetime object, and the UTC space that posix timestamps represent. The entire point of the datetime type (unless an explicit tzinfo is passed) is that it doesn't know which timezone it represents. When you call time.mktime(self.timetuple()), you as the application make the determination that the timetuple (which is still tz-unaware!) represents your current local time. That's a fine decision for the app to make. But I don't think users should be lured into believing there's an equivalency inherent in the datetime type -- there isn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1457227&group_id=5470 _______________________________________________ Patches mailing list Patches@python.org http://mail.python.org/mailman/listinfo/patches
