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.

Author gdr@garethrees.org
Recipients Arfrever, Eli_B, Niklas.Claesson, Ramchandra Apte, andrewclegg, anglister, belopolsky, gdr@garethrees.org, giampaolo.rodola, goshawk, lemburg, mark.dickinson, mdcb808@gmail.com, p-ganssle, python-dev, pythonhacker, r.david.murray, scoobydoo, serhiy.storchaka, tim.peters, tomikyos
Date 2021-12-18.16:09:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1639843750.36.0.0799620979309.issue15443@roundup.psfhosted.org>
In-reply-to
Content
I also have a use case that would benefit from nanosecond resolution in Python's datetime objects, that is, representing and querying the results of clock_gettime() in a program trace.

On modern Linuxes with a vDSO, clock_gettime() does not require a system call and completes within a few nanoseconds. So Python's datetime objects do not have sufficient resolution to distinguish between adjacent calls to clock_gettime().

This means that, like Mark Dickinson above, I have to choose between using datetime for queries (which would be convenient) and accepting that nearby events in the trace may be indistinguishable, or implementing my own datetime-like data structure.
History
Date User Action Args
2021-12-18 16:09:10gdr@garethrees.orgsetrecipients: + gdr@garethrees.org, lemburg, tim.peters, mark.dickinson, belopolsky, giampaolo.rodola, pythonhacker, Arfrever, r.david.murray, andrewclegg, python-dev, Ramchandra Apte, Eli_B, serhiy.storchaka, goshawk, Niklas.Claesson, mdcb808@gmail.com, scoobydoo, tomikyos, p-ganssle, anglister
2021-12-18 16:09:10gdr@garethrees.orgsetmessageid: <1639843750.36.0.0799620979309.issue15443@roundup.psfhosted.org>
2021-12-18 16:09:10gdr@garethrees.orglinkissue15443 messages
2021-12-18 16:09:10gdr@garethrees.orgcreate