10000 datetime.timestamp() lose precision when the time is too large · Issue #90683 · python/cpython · GitHub
[go: up one dir, main page]
Skip to content

datetime.timestamp() lose precision when the time is too large #90683

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
yilei mannequin opened this issue Jan 25, 2022 · 2 comments
Closed

datetime.timestamp() lose precision when the time is too large #90683

yilei mannequin opened this issue Jan 25, 2022 · 2 comments
Labels
extension-modules C modules in the Modules dir stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error

Comments

@yilei
Copy link
Mannequin
yilei mannequin commented Jan 25, 2022
BPO 46525
Nosy @yilei

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 2022-01-25.21:33:20.694>
labels = ['type-bug', '3.8', '3.9', '3.10', '3.11', '3.7', 'library']
title = 'datetime.timestamp() lose precision when the time is too large'
updated_at = <Date 2022-01-25.21:33:20.694>
user = 'https://github.com/yilei'

bugs.python.org fields:

activity = <Date 2022-01-25.21:33:20.694>
actor = 'yilei'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2022-01-25.21:33:20.694>
creator = 'yilei'
dependencies = []
files = []
hgrepos = []
issue_num = 46525
keywords = []
message_count = 1.0
messages = ['411676']
nosy_count = 1.0
nosy_names = ['yilei']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue46525'
versions = ['Python 3.7', 'Python 3.8', 'Python 3.9', 'Python 3.10', 'Python 3.11']
@yilei
Copy link
Mannequin Author
yilei mannequin commented Jan 25, 2022

Examples:

>>> datetime.datetime(2222, 1, 1, microsecond=999999).timestamp()
7952371200.999999
>>> datetime.datetime(3333, 1, 1, microsecond=999999).timestamp()
43012195201.0
>>> datetime.datetime(2567, 1, 1, microsecond=999998).timestamp()
18839548800.999996

I believe this is an issue caused by using double in the C implementation.

@yilei yilei mannequin added 3.7 (EOL) end of life 3.8 (EOL) end of life 3.9 only security fixes 3.10 only security fixes 3.11 only security fixes stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error labels Jan 25, 2022
@ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
@adienes adienes mentioned this issue Aug 13, 2023
Merged
@encukou encukou added extension-modules C modules in the Modules dir and removed 3.11 only security fixes 3.10 only security fixes 3.9 only security fixes 3.8 (EOL) end of life 3.7 (EOL) end of life labels Mar 14, 2025
@StanFromIreland
Copy link
Member
StanFromIreland commented Mar 14, 2025 •
edited
Loading 
>>> datetime.datetime(3333, 1, 1, microsecond=999998).timestamp()
43012166401.0
>>> datetime.datetime(3333, 1, 1, microsecond=99999).timestamp()
43012166400.1
>>> datetime.datetime(3333, 1, 1, microsecond=999991).timestamp()
43012166400.99999

Affects both C and Python implementation.

This is because Python uses float.

This is a duplicate of #91012 (It is newer but has had more discussion)

@encukou encukou closed this as completed Mar 24, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
extension-modules C modules in the Modules dir stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error
Projects
Date and time issues 🕰️
Archived in project
Milestone
No milestone
Development

No branches or pull requests
2 participants
@encukou @StanFromIreland
0