[Python-Dev] redux: fractional seconds in strptime

[Brett C.]

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 "704" represents the number of milliseconds, not the number of
> nanoseconds.
> 
> I'm sure that in some applications people are interested in extremely short
> time scales.  Writing out hours, minutes and seconds when all you are
> concerned with are small fractions of seconds (think high energy physics)
> would be a waste.  In those situations log entries like
> 
>     704 saw proton
>     705 proton hit neutron
>     706 saw electron headed toward Saturn
> 
> might make perfect sense.  Parsing the time field entirely within
> time.strptime would be at least clumsy if you couldn't tell it the scale of
> the numbers you're dealing with.  Parsing with %N, %3N or %6N would give
> different values (nanoseconds, milliseconds or microseconds).
> 

Fine, but couldn't you also do a pass over the data after extraction to get to 
the actual result you want (so parse, and take the millisecond value and 
multiply by the proper scale)?  This feels like it is YAGNI, or at least KISS. 
  If you want to handle milliseconds because of the logging module, fine.  But 
trying to deal with all possible time parsing possibilities is painful and 
usually not needed.

Personally I am more inclined to add a new directive that acts as %S but allows 
for an optional decimal point, comma or the current locale's separator if it 
isn't one of those two which will handle the logging package's optional decimal 
output ('\d+([,.%s]\d+)?" % locale.localeconv()['decimal_point']).  Also 
doesn't break any existing code.

And an issue I forgot to mention for all of this is it will break symmetry with 
time.strftime().  If symmetry is kept then an extra step in strftime will need 
to be handled since whatever solution we do will not match the C spec anymore.

-Brett