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 belopolsky
Recipients Arfrever, Niklas.Claesson, Ramchandra Apte, andrewclegg, belopolsky, ethan.furman, goshawk, lemburg, mdcb808@gmail.com, pitrou, pythonhacker, r.david.murray, scoobydoo, serhiy.storchaka, tim.peters, vstinner
Date 2015-04-09.01:47:47
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1428544068.55.0.714563541738.issue15443@psf.upfronthosting.co.za>
In-reply-to
Content
I have no doubt this will get into 3.x once we have a working patch and backward compatibility issues are addressed.  Given the amount of effort Victor has recently put in #22117 to rework CPython internal time handling to support nanoseconds, it will be odd not to support nanoseconds in datetime.

On the substance, in your patch you have chosen to add nanoseconds as a separate field instead of changing microseconds to nanoseconds.  I don't think this is the right approach.  See msg223082.  Once you get to implementing timedelta arithmetics, you will see that carrying two subsecond fields will unnecessarily complicate the code.
History
Date User Action Args
2015-04-09 01:47:48belopolskysetrecipients: + belopolsky, lemburg, tim.peters, pitrou, vstinner, pythonhacker, Arfrever, r.david.murray, andrewclegg, ethan.furman, Ramchandra Apte, serhiy.storchaka, goshawk, Niklas.Claesson, mdcb808@gmail.com, scoobydoo
2015-04-09 01:47:48belopolskysetmessageid: <1428544068.55.0.714563541738.issue15443@psf.upfronthosting.co.za>
2015-04-09 01:47:48belopolskylinkissue15443 messages
2015-04-09 01:47:47belopolskycreate