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: extend strptime to understand logging timestamps
Type: enhancement Stage:
Components: Library (Lib) Versions:
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: brett.cannon Nosy List: brett.cannon, jimjjewett, skip.montanaro
Priority: normal Keywords:

Created on 2004-08-10 18:59 by skip.montanaro, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
strptime.diff skip.montanaro, 2004-08-10 18:59
Messages (6)
msg54231 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2004-08-10 18:59
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.
msg54232 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2004-08-11 01:43
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?
msg54233 - (view) Author: Skip Montanaro (skip.montanaro) * (Python triager) Date: 2004-08-11 03:22
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.
msg54234 - (view) Author: Jim Jewett (jimjjewett) Date: 2004-08-11 15:59
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.
msg54235 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2004-08-11 18:17
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.
msg54236 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2006-08-24 01:15
Logged In: YES 
user_id=357491

Closing as rejected since this is not going to happen within
strptime itself.
History
Date User Action Args
2022-04-11 14:56:06adminsetgithub: 40737
2004-08-10 18:59:05skip.montanarocreate