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 brett.cannon
Recipients brett.cannon, eric.smith, skip.montanaro
Date 2007-09-13.19:35:31
SpamBayes Score 0.000324032
Marked as misclassified No
Message-id <>
In-reply-to <>
On 9/13/07, Skip Montanaro <> wrote:
> Skip Montanaro added the comment:
> Brett> Are you going to add support to strptime as well?
> I looked at strptime for about two seconds then moved on.  I presume you
> would know how to add it easily though. ;-)

Adding support is not issue.  It's exposing the microseconds to
datetime.  It would probably require something along the lines of
returning a tuple with microseconds included and have time use a
function that creates another tuple with that info removed and
datetime using the more informational tuple.

But adding the %f support is very straightforward.

>     Brett> As for the 'time' module, I don't think it would be useful as it serves
>     Brett> no purpose since the time tuple can't resolve to that
>     Brett> resolution.
> Resolution isn't the issue.  You just make sure you add enough zeroes to
> make it be microseconds.  The bigger problem is that time.strftime() takes a
> tuple of ints which basically represents a struct tm.  That struct has an
> int seconds field and no sub-second field.  You'd either have to start
> allowing floating point tm_sec fields then either truncating or rounding
> (but which?) to get ints when you need to actually generate an actual struct
> tm.

Right.  I am in favour of this being just a datetime thing as we
should get people moved off of time for stuff like this anyway.

Date User Action Args
2007-09-13 19:35:32brett.cannonsetspambayes_score: 0.000324032 -> 0.000324032
recipients: + brett.cannon, skip.montanaro, eric.smith
2007-09-13 19:35:31brett.cannonlinkissue1158 messages
2007-09-13 19:35:31brett.cannoncreate