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.

classification
Title: %f format for datetime objects
Type: enhancement Stage:
Components: Extension Modules Versions: Python 3.0
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: skip.montanaro Nosy List: brett.cannon, eric.smith, skip.montanaro
Priority: normal Keywords: patch

Created on 2007-09-13 02:26 by skip.montanaro, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
datetime-f.diff skip.montanaro, 2007-12-10 04:19
Messages (15)
msg55876 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2007-09-13 02:26
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.
msg55878 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2007-09-13 06:33
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.
msg55880 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2007-09-13 07:12
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 */
msg55889 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2007-09-13 12:59
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
msg55890 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2007-09-13 13:00
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
msg55896 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2007-09-13 19:35
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
msg55947 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2007-09-17 01:22
Here are new patches for 2.6 and 3.0 including changes
to doc and test cases.
msg55964 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2007-09-17 13:50
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
msg55966 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2007-09-17 16:12
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
>
>
msg55976 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2007-09-17 20:25
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
msg58324 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2007-12-09 20:21
Okay, here's my latest patch (datetime-f.diff).  2.6 only at this point.
msg58325 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2007-12-09 20:34
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.
msg58327 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2007-12-09 20:44
Updated diff.  Just a tweak to datetime.rst.
msg58339 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2007-12-10 04:19
Stop me before I update it again!  This update touches up
datetime_strptime a bit.  It's more uniform and a bit faster.
msg63549 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2008-03-15 16:05
Checking this in.  All tests pass.  Have for quite awhile.
rev 61402.
History
Date User Action Args
2022-04-11 14:56:26adminsetgithub: 45499
2008-03-29 01:37:16georg.brandlsetstatus: open -> closed
resolution: accepted
2008-03-15 16:05:22skip.montanarosetassignee: skip.montanaro
messages: + msg63549
2008-01-06 22:29:45adminsetkeywords: - py3k
versions: Python 3.0
2007-12-10 04:19:56skip.montanarosetfiles: - datetime-f.diff
2007-12-10 04:19:46skip.montanarosetfiles: + datetime-f.diff
messages: + msg58339
2007-12-09 20:44:41skip.montanarosetfiles: - datetime-f.diff
2007-12-09 20:44:33skip.montanarosetfiles: - dt-30.diff
2007-12-09 20:44:17skip.montanarosetfiles: + datetime-f.diff
messages: + msg58327
2007-12-09 20:34:57skip.montanarosetmessages: + msg58325
2007-12-09 20:21:19skip.montanarosetfiles: - dt-26.diff
2007-12-09 20:21:09skip.montanarosetfiles: + datetime-f.diff
messages: + msg58324
2007-09-17 20:25:40skip.montanarosetmessages: + msg55976
2007-09-17 16:12:44brett.cannonsetmessages: + msg55966
2007-09-17 13:50:09skip.montanarosetmessages: + msg55964
2007-09-17 01:23:02skip.montanarosetfiles: + dt-30.diff
2007-09-17 01:22:41skip.montanarosetfiles: + dt-26.diff
messages: + msg55947
2007-09-17 01:21:54skip.montanarosetfiles: - percent-f.diff
2007-09-13 19:35:31brett.cannonsetmessages: + msg55896
2007-09-13 13:00:07skip.montanarosetmessages: + msg55890
2007-09-13 12:59:38skip.montanarosetmessages: + msg55889
2007-09-13 07:12:14eric.smithsetnosy: + eric.smith
messages: + msg55880
2007-09-13 06:33:11brett.cannonsetnosy: + brett.cannon
messages: + msg55878
2007-09-13 02:26:43skip.montanarocreate