Patches item #1689402, was opened at 2007-03-27 20:51 Message generated for change (Comment added) made by tiran You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1689402&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: Core (C code) Group: Python 2.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Christian Heimes (tiran) Assigned to: Nobody/Anonymous (nobody) Summary: Replace time_t by Py_time_t Initial Comment: In the thread "datetime module enhancements" Guido and others said that it is unpythonic to limit timestamp (seconds since Epoch) to an signed int with 32bit. http://permalink.gmane.org/gmane.comp.python.devel/86750 I've made a patch that introduces a new type Py_time_t as a first step to increase the size of time stamps. For now it's just an alias for time_t. typedef time_t Py_time_t; I'm proposing to change time_t in two steps: Python 2.6: Replace every occurrence of time_t by Py_time_t and give third party authors time to change their software Python 2.7 / 3000: Change Py_time_t to a signed 64bit int on all platforms and provide the necessary workaround for platforms with a 32bit time_t. ---------------------------------------------------------------------- >Comment By: Christian Heimes (tiran) Date: 2007-03-28 16:48 Message: Logged In: YES user_id=560817 Originator: YES Yes, you are right. There is no place where the ptch checks for truncating - because the patch doesn't change the size of time_t. The current patch defines Py_time_t is an alias for time_t so 3rd party authors can update their software to use Py_time_t instead of time_t in Python 2.6. Also it gives me time to study the impacts on systems with a 32bit time_t and to get feedback from core developers. May we take the discussion to python-ideas? I've started a thread yesterday. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2007-03-28 13:41 Message: Logged In: YES user_id=21627 Originator: NO After a shallow review, I think the patch is incorrect. There must be places where a Py_time_t may get truncated to a time_t; in these places, no silent truncation should occur, but an exception be raised. I can find no place in the patch where this happens. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1689402&group_id=5470 _______________________________________________ Patches mailing list [email protected] http://mail.python.org/mailman/listinfo/patches
