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 SilentGhost
Recipients SilentGhost, acucci, belopolsky, berker.peksag, cvrebert, elixir, ezio.melotti, gvanrossum, jerry.elmore, lemburg, martin.panter, matrixise, terry.reedy, tim.peters, vstinner
Date 2016-01-17.22:07:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1453068432.78.0.494378089308.issue19475@psf.upfronthosting.co.za>
In-reply-to
Content
> What about milliseconds?  I'll leave it for Guido to make a call on nanoseconds.  My vote is +0.5.
The only reason I didn't mention milliseconds because they exist in timedelta instantiation. And really, being the only place in the whole module they're as confusing there as would be nanoseconds.

> > If they don't
> > exist anywhere else in the module, why should they be suddenly 
> > introduced here?

> The timespec feature is modeled after GNU date --iso-8601[=timespec] option which does support nanoseconds.  It is fairly common to support nanoseconds these days and it does not cost much to implement.

Yes, but the module does not support nanoseconds. And putting any such options would require a huge banner saying that the nanosecond option will just always result in three zeros at the end. My suggestion is not to pretend that we suddenly "support" nanoseconds, but rather to follow the actual implementation of the module and add the support for nanoseconds timespec when the module actually adds support for them.
History
Date User Action Args
2016-01-17 22:07:12SilentGhostsetrecipients: + SilentGhost, lemburg, gvanrossum, tim.peters, terry.reedy, belopolsky, vstinner, ezio.melotti, cvrebert, berker.peksag, martin.panter, matrixise, elixir, jerry.elmore, acucci
2016-01-17 22:07:12SilentGhostsetmessageid: <1453068432.78.0.494378089308.issue19475@psf.upfronthosting.co.za>
2016-01-17 22:07:12SilentGhostlinkissue19475 messages
2016-01-17 22:07:12SilentGhostcreate