Issue 1689402: Replace time_t by Py_time_t (original) (raw)

Issue1689402

This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

This issue has been migrated to GitHub: https://github.com/python/cpython/issues/44775

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 2022-04-11 14:56 by admin. 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
2022-04-11 14:56:23 admin set github: 44775
2008-01-19 14:21:56 christian.heimes set status: open -> closedresolution: rejectedmessages: +
2007-03-27 18:51:54 christian.heimes create