You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 to required_fields and "asctime": "timestamp" to rename_fields. Though then what do we do if asctime and timestamp 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.
Do we support time zones that aren't UTC?
What about users still using asctime, datefmt, and converter?
Searching old issues - it looks like there people who are using these to control the output of asctime.
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
The text was updated successfully, but these errors were encountered:
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 usesconverter=time.localtime
anddatefmt
.It feels like instead it should be a
datetime
encoded by the JSON encoder. However doing this would raise other questions like:datefmt
argument?converter
attribute?timestamp
argument?asctime
torequired_fields
and"asctime": "timestamp"
torename_fields
. Though then what do we do ifasctime
andtimestamp
are used?timestamp
was added included in the commit that added it. Searching old issues doesn't surface anything either.asctime
,datefmt
, andconverter
?asctime
.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
andconverter
). 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
overasctime
.Opinions welcome
The text was updated successfully, but these errors were encountered: