Description
Currently using the asctime
field will produce a string that is formatted separately from the JSON encoders.
By default it is produced by logging.Formatter.formatTime
which uses converter=time.localtime
and datefmt
.
It feels like instead it should be a datetime
encoded by the JSON encoder. However doing this would raise other questions like:
- What do we do with the
datefmt
argument? - What do we do with the
converter
attribute? - Do we remove the
timestamp
argument?- This could be converted to an alias that adds
asctime
torequired_fields
and"asctime": "timestamp"
torename_fields
. Though then what do we do ifasctime
andtimestamp
are used? - I'll note that there doesn't appear to be any reasoning for why
timestamp
was added included in the commit that added it. Searching old issues doesn't surface anything either.
- This could be converted to an alias that adds
- Do we support time zones that aren't UTC?
- What about users still using
asctime
,datefmt
, andconverter
?- Searching old issues - it looks like there people who are using these to control the output of
asctime
.
- Searching old issues - it looks like there people who are using these to control the output of
As such any decision to move to using the JSON encoder or changing / removing timestamp
is likely a breaking change which we probably want to avoid for as long as possible.
Another approach would be to set "saner" defaults for formatTime
or (datefmt
and converter
). This could be considered a non-breaking change (anyone using defaults would experience the change, but anyone using custom shouldn't see breakages).
Another approach would be to use some kind of "opt-in" keyword argument that toggles new behaviour and otherwise uses old behaviour.
Perhaps in the short term all we do is update the docs to suggest that using timestamp
over asctime
.
Opinions welcome