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, mdcb808@gmail.com, 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 <1474058294.81.0.704335473154.issue15443@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
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, mdcb808@gmail.com, scoobydoo, tomikyos
2016-09-16 20:38:14holdenwebsetmessageid: <1474058294.81.0.704335473154.issue15443@psf.upfronthosting.co.za>
2016-09-16 20:38:14holdenweblinkissue15443 messages
2016-09-16 20:38:14holdenwebcreate