| msg55876 - (view) |
Author: Skip Montanaro (skip.montanaro) *  |
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) *  |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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) * |
Date: 2007-12-09 20:44 |
| Updated diff. Just a tweak to datetime.rst. |
|
|
| msg58339 - (view) |
Author: Skip Montanaro (skip.montanaro) * |
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) * |
Date: 2008-03-15 16:05 |
| Checking this in. All tests pass. Have for quite awhile. rev 61402. |
|
|