Logging module and datetime - oil & water for some reason?

Skip Montanaro skip.montanaro at gmail.com
Mon Apr 1 16:54:03 EDT 2019

I assiduously avoided using Python's logging package for about the
first dozen years of its existence. I eventually gave in and started
using it relatively recently in the guise of a thin wrapper provided
by a colleague at work. Today I had occasion to tweak the timestamp
format only to discover that logging still uses time.localtime or
time.gmtime as its underlying source of time fields, so subsecond
timestamps are hacked in, with no straightforward way to log both
milliseconds and the timezone in normal order. I have need for both,
as I work for a company with offices in multiple timezones, and
sometimes need subsecond time resolution for quick-n-dirty analysis.

I stole a custom formatter class from a StackOverflow thread and am
now back in business (milliseconds *and* timezones, yay!). Still,
peeking at the 2.7 documentation, I see that both the logging package
and the datetime module were added to the standard library in Python
2.3 (2003). Why is logging still relying on the suboptimal
time.{localtime,gmtime} API? Surely, if there was no
backwards-compatible way to introduce datetime into the system, a
small breaking change could have been made for Python 3000 and
probably affected very few users.


More information about the Python-list mailing list