Attached is a patch for py3k which adds a %f format code to its strftime
method.  When included in a format string it expands to the number of
microseconds in the object.  date, time and datetime objects all support
the format (though I'm not sure what, if anything, it means for date
objects).

I don't know how practical this is for time.strftime() level because the
inputs are all so excited about being ints.  Still, if you wanted to
allow the seconds field to be a float and were willing to cast it to an
int where necessary and shadow struct tm with a pseudo-float-friendly
version of the same, you could probably smash it in there as well.

Are you going to add support to strptime as well?

As for the 'time' module, I don't think it would be useful as it serves
no purpose since the time tuple can't resolve to that resolution.  If
you do add support, though, I guess you just default to 0.

It's a nit, but there are a few other comments that should be changed to
mention %f in addition to %z/%Z.

 * giving special meanings to the %z and %Z format codes via a preprocessing

	/* Scan the input format, looking for %z and %Z escapes, building

			/* percent followed by neither z nor Z */

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. ;-)

    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.

Skip

Eric> It's a nit, but there are a few other comments that should be
    Eric> changed to mention %f in addition to %z/%Z.

Yes, thanks.

Skip

On 9/13/07, Skip Montanaro <report@bugs.python.org> 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.

-Brett

Here are new patches for 2.6 and 3.0 including changes
to doc and test cases.

Brett,

Continuing the discussion of strptime... It returns a time.struct_time.
Would it cause too much breakage (only do this in 3.0) to add a tm_usec
field to the end of that object?  It seems a lot of bits of code might
still expect a length 9 tuple-ish thing and do this:

  yy, mm, dd, hh, mm, ss, wk, j, tz = time.strptime(...)

If we could make that change for 3.0 that might allow strptime to parse
%f format codes.

S

In terms of strptime, I would just change _strptime.strptime() to
_strptime._strptime() and have it return everything along with the
microseconds measurement.  Then have public functions that call that
function and either strip off the microseconds or not.

-Brett

On 9/17/07, Skip Montanaro <report@bugs.python.org> wrote:
>
> Skip Montanaro added the comment:
>
> Brett,
>
> Continuing the discussion of strptime... It returns a time.struct_time.
> Would it cause too much breakage (only do this in 3.0) to add a tm_usec
> field to the end of that object?  It seems a lot of bits of code might
> still expect a length 9 tuple-ish thing and do this:
>
>   yy, mm, dd, hh, mm, ss, wk, j, tz = time.strptime(...)
>
> If we could make that change for 3.0 that might allow strptime to parse
> %f format codes.
>
> S
>
> __________________________________
> Tracker <report@bugs.python.org>
> <http://bugs.python.org/issue1158>
> __________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/brett%40python.org
>
>

Brett> In terms of strptime, I would just change _strptime.strptime() to
    Brett> _strptime._strptime() and have it return everything along with
    Brett> the microseconds measurement.  Then have public functions that
    Brett> call that function and either strip off the microseconds or not.

Sounds good.  I'll work that into my patch(es).

Skip

Okay, here's my latest patch (datetime-f.diff).  2.6 only at this point.

Actually, I think I will avoid the 3.0 patch altogether and let these
changes propagate from trunk to py3k by whoever works that magic.

Updated diff.  Just a tweak to datetime.rst.

Stop me before I update it again!  This update touches up
datetime_strptime a bit.  It's more uniform and a bit faster.

Checking this in.  All tests pass.  Have for quite awhile.
rev 61402.