Repository navigation
datetime module should use int32_t for date/time components #53280
Description
| BPO | 9034 |
|---|---|
| Nosy | @mdickinson, @abalkin |
| Dependencies |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2010-06-20.01:44:15.435>
labels = ['extension-modules', 'type-feature']
title = 'datetime module should use int32_t for date/time components'
updated_at = <Date 2014-10-15.13:46:18.024>
user = 'https://github.com/abalkin'bugs.python.org fields:
activity = <Date 2014-10-15.13:46:18.024>
actor = 'belopolsky'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Extension Modules']
creation = <Date 2010-06-20.01:44:15.435>
creator = 'belopolsky'
dependencies = ['17884']
files = []
hgrepos = []
issue_num = 9034
keywords = []
message_count = 2.0
messages = ['108222', '229447']
nosy_count = 2.0
nosy_names = ['mark.dickinson', 'belopolsky']
pr_nums = []
priority = 'low'
resolution = None
stage = 'needs patch'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue9034'
versions = ['Python 3.5']
Activity
abalkin commentedon Jun 20, 2010
"""
As an aside, I dislike the fact that the datetime module uses a C 'int' for date ordinals, and clearly assumes that it'll be at least 32 bits. int could be as small as 16 bits on some systems (small embedded systems?). But that's another issue.
""" -- Mark Dickinson
A comment and an assertion at the top of the module suggest that this was deliberate.
However, since ranges of all integers are well defined in this module, there is little to be gained from the uncertainty about sizes of int and long. (For example, the allowed range of dates will not magically increase on a platform with 64 bit ints.)
I propose using explicitly sized C99 types int32_t and int64_t or rather their blessed for use in python equivalents PY_INTXX_T) throughout the module.
abalkin commentedon Oct 15, 2014
See also bpo-17884.
StanFromIreland commentedon Feb 16, 2025
I vote to close as this is necessary as the current error is enough and I cannot find any example of anyone annoyed it's not used (as they are using an archaic machine) reporting this.
encukou commentedon Feb 17, 2025
Right. We don't test with 16-bit ints, so this assumption might be silently made elsewhere. The datetime module is nice enough to assert it.
I'll close so issue to remove it from the project's "TODO list". If anyone wants to fix this, re-open or make a new issue.