Brett> Everyone went silent on this topic. Does this mean people just
Brett> stopped caring (which I doubt since I know Skip wants this bad
Brett> enough to bring it up every so often)? Was it the issue of
Brett> symmetry with strftime?
I have a patch to do strptime() fractional
Everyone went silent on this topic. Does this mean people just stopped caring
(which I doubt since I know Skip wants this bad enough to bring it up every so
often)? Was it the issue of symmetry with strftime?
I am willing to add this (albeit the simple way I proposed in my last email on
this
Skip Montanaro wrote:
>> I realize the %4N notation is distasteful, but without it I think you
>> will have trouble parsing something like
>>
>> 13:02:00.704
>>
>> What would be the format string? %H:%M:%S.%N would be incorrect.
Brett> Why is that incorrect?
Because
On Fri, Jan 14, 2005, Alex Martelli wrote:
> On 2005 Jan 14, at 19:11, Aahz wrote:
>>On Fri, Jan 14, 2005, Brett C. wrote:
>>>
>>>Right, it's a struct_time object; just force of habit to call it a
>>>time tuple.
>>>
>>>And I technically don't see why a fractional second attribute could
>>>not be ad
On 2005 Jan 14, at 19:11, Aahz wrote:
On Fri, Jan 14, 2005, Brett C. wrote:
Right, it's a struct_time object; just force of habit to call it a
time
tuple.
And I technically don't see why a fractional second attribute could
not be
added that is not represented in the tuple. But I personally woul
>> I realize the %4N notation is distasteful, but without it I think you
>> will have trouble parsing something like
>>
>> 13:02:00.704
>>
>> What would be the format string? %H:%M:%S.%N would be incorrect.
Brett> Why is that incorrect?
Because "704" represents the
On Fri, Jan 14, 2005, Brett C. wrote:
>
> Right, it's a struct_time object; just force of habit to call it a time
> tuple.
>
> And I technically don't see why a fractional second attribute could not be
> added that is not represented in the tuple. But I personally would like to
> see struct_tm
Skip Montanaro wrote:
Brett> The problem I have always had with this proposal is that the
Brett> value is worthless, time tuples do not have a slot for fractional
Brett> seconds. Yes, it could possibly be changed to return a float for
Brett> seconds, but that could possibly break t
On Fri, 2005-01-14 at 09:36, Skip Montanaro wrote:
> Actually, time.strptime() returns a struct_time object. Would it be
> possible to extend %S to parse floats then add a microseconds (or whatever)
> field to struct_time objects that is available by attribute only?
+1 for adding a microseconds f
On Fri, 2005-01-14 at 06:40, Alex Martelli wrote:
> +1 -- I never liked the idea that 'time tuples' lost fractions of a
> second. On platforms where that's sensible and not too hard,
> time.time() could also -- unobtrusively and backwards compatibly -- set
> that same attribute. I wonder if,
On 2005 Jan 14, at 10:36, Skip Montanaro wrote:
Brett> The problem I have always had with this proposal is that the
Brett> value is worthless, time tuples do not have a slot for
fractional
Brett> seconds. Yes, it could possibly be changed to return a
float for
Brett> seconds, but
Brett> The problem I have always had with this proposal is that the
Brett> value is worthless, time tuples do not have a slot for fractional
Brett> seconds. Yes, it could possibly be changed to return a float for
Brett> seconds, but that could possibly break things.
Actually, tim
Skip Montanaro wrote:
A couple months ago I proposed (maybe in a SF bug report)
http://www.python.org/sf/1006786
that
time.strptime() grow some way to parse time strings containing fractional
seconds based on my experience with the logging module. I've hit that
stumbling block again, this time in
A couple months ago I proposed (maybe in a SF bug report) that
time.strptime() grow some way to parse time strings containing fractional
seconds based on my experience with the logging module. I've hit that
stumbling block again, this time in parsing files with timestamps that were
generated using
14 matches
Mail list logo
