[ python-Feature Requests-1006786 ] extend strptime to understand logging timestamps

[SourceForge.net]

Feature Requests item #1006786, was opened at 2004-08-10 11:59
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1006786&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Brett Cannon (bcannon)
Summary: extend strptime to understand logging timestamps

Initial Comment:
The default timestamp format used by the logging module
appends
a comma followed by a three-digit value representing
milliseconds,
e.g.:

    2004-08-10 08:21:20,380 DEBUG <mytag> log message here

It would be nice if time.strptime() grokked this
specification for
the seconds in a timestamp so that applications which
want to
analyze log files can do so more easily.  One
possibility is to
add a %s format specifier which recognizes NN,MMM as a
floating point value containing fractional seconds with
a comma
as the "decimal point".

Attached is a simple patch.  I chose %s as the format
sequence
since it is related to %S.


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2006-08-23 18:15

Message:
Logged In: YES 
user_id=357491

Closing as rejected since this is not going to happen within
strptime itself.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-08-11 11:17

Message:
Logged In: YES 
user_id=357491

Jim is right; dateFormat() in the Formatter class in Lib/logging/
__init__.py seems to handle formatting of timestamps.  Now looking at 
the code it seems to store the format in self.datefmt, but it is set to 
None by default.  Then in dateFormat(), if self.datefmt is None it uses 
the default format.

The problem is that the millisecond part of the timestamp is not 
supported by time tuples.  strftime doesn't even support it (if you  look 
at timeFormat(), it kind of cheats and passes everything *but* the 
millisecond time to strftime and then just tacks on the millisecond 
stamp) so it seems a little off to add support just in strptime.  Kind of 
too bad since it means that there is no way to actually construct  the 
default timestamp yourself; timeFormat, if given a value other than None 
just passes the format string through strftime.

And look at datetime.  It supports *microsecond* values in its time class 
and strftime can't support that either.  So now we have two places in the 
stdlib where they use  stuff that strftime (and thus strptime) can't 
support.  And of course  the logging module doesn't use datetime since it 
is  keeping 1.5.2 compatibility, so we can't solve all our problems with 
just a fix for datetime or by subclassing stuff in _strptime and coming up 
with a custom strptime for the logging module.

So honestly I don't know what a good solution would be since not having 
symmetry with strftime is not acceptable.  I can only think of having a 
small wrapper function in the logging module that handles the 
millisecond part and passes the rest through strptime.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-08-11 08:59

Message:
Logged In: YES 
user_id=764593

The format changes; "##,###" is just the default.

It is based on an ISO recommendation, including the use of "," 
rather than "." to indicate a decimal point.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2004-08-10 20:22

Message:
Logged In: YES 
user_id=44345

Whatever works.  I hope we don't need a PEP for this.  One way
or the other I think it would be great if strptime can grok the
logging module's timestamp.  I haven't looked carefully at it
to see if its timestamp format is variable or fixed.  I suppose
that will have a lot to do with how the parsing problem is
solved in _strptime.


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-08-10 18:43

Message:
Logged In: YES 
user_id=357491

Is this the best solution, or would it be better to just have a specific 
logging module directive (either in the logging package or in strptime) 
that recognized the whole string?  If that format *never* changes, then 
we could just simplify it by having a single directive to make life easier 
for everyone involved.

If we are going to compromise on adding a special directive for the 
logging module might as well go all the way, right?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1006786&group_id=5470