classification
Title: Replace time_t by Py_time_t
Type: Stage:
Components: Interpreter Core Versions: Python 2.6
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: christian.heimes, loewis
Priority: normal Keywords: patch

Created on 2007-03-27 18:51 by christian.heimes, last changed 2008-01-19 14:21 by christian.heimes. This issue is now closed.

Files
File name Uploaded Description Edit
pytimet.diff christian.heimes, 2007-03-27 18:51 Patch against trunk r54585
Messages (4)
msg52311 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2007-03-27 18:51
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.
msg52312 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2007-03-28 11:41
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.
msg52313 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2007-03-28 14:48
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.
msg60169 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2008-01-19 14:21
I reject my own proposal.
History
Date User Action Args
2008-01-19 14:21:56christian.heimessetstatus: open -> closed
resolution: rejected
messages: + msg60169
2007-03-27 18:51:54christian.heimescreate