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 holdenweb
Recipients Arfrever, Niklas.Claesson, Ramchandra Apte, andrewclegg, belopolsky, goshawk, holdenweb, lemburg,, pythonhacker, r.david.murray, scoobydoo, serhiy.storchaka, tim.peters, tomikyos, vstinner
Date 2016-09-16.20:38:14
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I agree on reflection that a single nanoseconds integral value makes more sense. This then requires refactoring of the existing code so that existing tests continue to pass using a microsecond property.

Code using ONLY nanoseconds is a disjoint case, for which new tests will be required. It clearly cannot be expected to be backwards compatible with pre-implementation versions.

Does it make sense to define behaviour for cases where the user attempts to MIX microseconds and nanoseconds? One validation I would suggest if so is that in the presence of a microseconds specification a constraint of 0 <= nanoseconds < 1000 must be imposed.
Date User Action Args
2016-09-16 20:38:15holdenwebsetrecipients: + holdenweb, lemburg, tim.peters, belopolsky, vstinner, pythonhacker, Arfrever, r.david.murray, andrewclegg, Ramchandra Apte, serhiy.storchaka, goshawk, Niklas.Claesson,, scoobydoo, tomikyos
2016-09-16 20:38:14holdenwebsetmessageid: <>
2016-09-16 20:38:14holdenweblinkissue15443 messages
2016-09-16 20:38:14holdenwebcreate