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

[DL Neil]

Skip,


On 2/04/19 9:54 AM, Skip Montanaro wrote:
> I assiduously avoided using Python's logging package for about the
> first dozen years of its existence. I eventually gave in and started

I'm glad you're stepping-up!

I'm never sure whether to be amazed or dismayed by the huge number of 
folk expressing/hiding this sort of 'fear'.
(not that I'm insulting you - you might be bigger than I!)

Have spent some time over the last two days, contemplating an 'upgrade' 
from ordinary files to a RotatingFileHandler, so, with the manual fresh 
in my mind, you're in-luck!
(maybe)


> 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.

Prepare for that "thin wrapper" (and most of the provided 'convenience 
functions') to disappear in your rear-view mirror!


> 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.

The formatTime method was added to the Formatter class in Python 3.3. 
(see docs, if v3.3 is an option available to you)

Otherwise, your idea of implementing a sub-class was likely the best 
approach.

Another introduction (v3.2) has been LoggerAdapter objects. I've not 
used them(!) but wondered if they might have purpose in such situations?

In multi-national situations, my recommendation has long been to 
standardise all times (incl logging) as UTC.

I'm not sure if it was available as far back as Py2, but there is a 
SysLogHandler() which enables disparate and dispersed applications to 
log to a central 'logging server'. (although I wonder if the formatters 
would still be using local time (or whatever), or if the 'time' relates 
to that central server)

Am unable to comment on, or answer, the last question.

-- 
Regards =dn