Title: logging.Formatter does not default to ISO8601 date format
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.8, Python 3.7, Python 3.6
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: ned.deily, p-ganssle, paulc, vinay.sajip
Priority: normal Keywords: patch

Created on 2018-05-01 19:37 by paulc, last changed 2018-06-01 17:55 by vinay.sajip. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 6702 merged vinay.sajip, 2018-05-04 19:54
PR 6703 merged miss-islington, 2018-05-04 21:21
PR 6704 merged miss-islington, 2018-05-04 21:22
PR 7297 merged vinay.sajip, 2018-06-01 08:09
PR 7302 merged miss-islington, 2018-06-01 09:14
PR 7303 merged miss-islington, 2018-06-01 09:15
Messages (14)
msg316012 - (view) Author: Paul Cyr (paulc) Date: 2018-05-01 19:37
From the docs:

"class logging.Formatter(fmt=None, datefmt=None, style='%') ...
If no datefmt is specified, the ISO8601 date format is used."

However, the output from the formatter when no datefmt is specified is not an ISO8601 date. It is also a datetime format, not a date format.

Example output: 2018-05-01 19:04:31,505

Not being an ISO member, I don't have access to the official source for the specification but, trusting other sources, it appears that the output is missing the required 'T' delimiter between the date and time, and it is also missing the timezone. A compliant output would be:


The current output appears to actually be closer to RFC 3339, as that standards allows for a space instead of the 'T' delimiter, but RFC 3339 still requires a timezone.

Either the documentation should be updated to state that the format used is an RFC 3339 datetime but without a timezone, or the format should comply with the standard specified in the documentation.
msg316013 - (view) Author: Paul Ganssle (p-ganssle) * (Python committer) Date: 2018-05-01 19:56
ISO 8601 does not require an offset (in fact, most portions of the ISO 8601 date and time are optional - ISO 8601 is more complicated than most people think). Without an offset a datetime is assumed to be local time.

The T delimiter is required, but can be omitted by mutual consent, see
msg316185 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2018-05-04 21:21
New changeset c4994dc00d9828a99510f3851da93b0e1c18361d by Vinay Sajip in branch 'master':
bpo-33400: Clarified documentation to indicate no strict adherence to ISO 8601. (GH-6702)
msg316187 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2018-05-04 22:02
New changeset eb5abdc70815c4207829551ede4a7dc302d56c19 by Vinay Sajip (Miss Islington (bot)) in branch '3.6':
bpo-33400: Clarified documentation to indicate no strict adherence to ISO 8601. (GH-6703)
msg316662 - (view) Author: Paul Ganssle (p-ganssle) * (Python committer) Date: 2018-05-15 15:02
I don't really agree with these changes to the documentation.

The format that paulc identifies is actually an RFC 3339 datetime, which is a subset of ISO 8601, to the extent that you consider the fact that "we're using RFC 3339" is "mutual consent" for omitting the `T` separator. The changes to the documentation make it more confusing because it's not clear how precisely the datetime is considered to deviate from the spec.

I think I would change the documentation to refer to the format as RFC 3339 and if ISO 8601 is mentioned at all, it can be parenthetical in the first mention.

In any case, exposing the spec like this would probably be useful:


The fact that this complies with the RFC 3339 spec (particularly as commonly implemented) just means "an ISO parser that implements the spec should be able to read this".
msg317756 - (view) Author: Ned Deily (ned.deily) * (Python committer) Date: 2018-05-26 18:45
Vinay, PR_6704, the 3.7 backport is still unmerged with review comments and there are unresolved comments here.  Can we at least get the 3.7 branch in sync with the other branches while you sort this out one way or another?
msg317767 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2018-05-26 21:20
Yes, sorry, Ned, I've been snowed under with other work recently :-(
msg317841 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2018-05-28 12:29
New changeset eb8516becc267caeb0ca6f9c41e805d1ba1caaa3 by Vinay Sajip (Miss Islington (bot)) in branch '3.7':
bpo-33400: Clarified documentation to indicate no strict adherence to ISO 8601. (GH-6702) (GH-6704)
msg317842 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2018-05-28 12:36
Because the specs allow certain decisions to be taken "by mutual consent", I'm not sure anyone can be really happy. Perhaps I should just state what the format actually is, as per msg316662, refer to RFC 3339 and leave it at that.

I don't have a copy of the ISO 8601 standard and so can't confirm exactly what it states.
msg317843 - (view) Author: Paul Ganssle (p-ganssle) * (Python committer) Date: 2018-05-28 12:49
I think this is more a matter of misunderstanding the fact that ISO 8601 is a larger and more complicated spec than people think.  You'll note that the original complaint also seems to think that a timezone is required (it is not). You can find a copy of RFC 3339 here:

Which states:

      NOTE: ISO 8601 defines date and time separated by "T".
      Applications using this syntax may choose, for the sake of
      readability, to specify a full-date and full-time separated by
      (say) a space character.

I think this is sufficient to refer to this as an RFC 3339 datetime, as a spec-compliant parser should be able to handle it just fine. Then there is no need for "x-like" anywhere in the documentation, which is just confusing. I do agree that the precise spec should be given.
msg317845 - (view) Author: Paul Ganssle (p-ganssle) * (Python committer) Date: 2018-05-28 12:55
Ah, actually, my mistake, RFC 3339 most assuredly *does* require a UTC offset:

   4.4. Unqualified Local Time

   A number of devices currently connected to the Internet run their
   internal clocks in local time and are unaware of UTC.  While the
   Internet does have a tradition of accepting reality when creating
   specifications, this should not be done at the expense of
   interoperability.  Since interpretation of an unqualified local time
   zone will fail in approximately 23/24 of the globe, the
   interoperability problems of unqualified local time are deemed
   unacceptable for the Internet.  Systems that are configured with a
   local time, are unaware of the corresponding UTC offset, and depend
   on time synchronization with other Internet systems, MUST use a
   mechanism that ensures correct synchronization with UTC.  Some
   suitable mechanisms are:

This is not true of ISO 8601, but dropping all references to RFC 3339 or ISO 8601 is fine with me.
msg318375 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2018-06-01 09:09
New changeset 23cee80cfade1a9019c52b3a17d8e5c1b5db17e2 by Vinay Sajip in branch 'master':
bpo-33400: Removed references to RFC3339 and ISO8601 from the logging documentation. (GH-7297)
msg318444 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2018-06-01 17:54
New changeset 4b6691e40f004bf3a08b1843620f5f6028d2b79d by Vinay Sajip (Miss Islington (bot)) in branch '3.7':
bpo-33400: Removed references to RFC3339 and ISO8601 from the logging documentation. (GH-7297) (GH-7302)
msg318445 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2018-06-01 17:55
New changeset 461ad598d12eba7754181402e00bb7cfc7f1d9cf by Vinay Sajip (Miss Islington (bot)) in branch '3.6':
bpo-33400: Removed references to RFC3339 and ISO8601 from the logging documentation. (GH-7297) (GH-7303)
Date User Action Args
2018-06-01 17:55:13vinay.sajipsetmessages: + msg318445
2018-06-01 17:54:35vinay.sajipsetmessages: + msg318444
2018-06-01 09:15:00miss-islingtonsetpull_requests: + pull_request6934
2018-06-01 09:14:00miss-islingtonsetpull_requests: + pull_request6933
2018-06-01 09:10:46vinay.sajipsetstatus: open -> closed
resolution: fixed
stage: patch review -> resolved
2018-06-01 09:09:24vinay.sajipsetmessages: + msg318375
2018-06-01 08:09:12vinay.sajipsetpull_requests: + pull_request6926
2018-05-28 12:55:25p-gansslesetmessages: + msg317845
2018-05-28 12:49:05p-gansslesetmessages: + msg317843
2018-05-28 12:36:58vinay.sajipsetmessages: + msg317842
2018-05-28 12:29:15vinay.sajipsetmessages: + msg317841
2018-05-26 21:20:25vinay.sajipsetmessages: + msg317767
2018-05-26 18:45:58ned.deilysetversions: + Python 3.6, Python 3.7, Python 3.8, - Python 3.4
2018-05-26 18:45:44ned.deilysetnosy: + ned.deily
messages: + msg317756
2018-05-15 15:02:41p-gansslesetmessages: + msg316662
2018-05-04 22:02:51vinay.sajipsetmessages: + msg316187
2018-05-04 21:22:30miss-islingtonsetpull_requests: + pull_request6396
2018-05-04 21:21:39miss-islingtonsetpull_requests: + pull_request6395
2018-05-04 21:21:03vinay.sajipsetmessages: + msg316185
2018-05-04 19:54:47vinay.sajipsetkeywords: + patch
stage: patch review
pull_requests: + pull_request6394
2018-05-01 19:56:41p-gansslesetnosy: + p-ganssle
messages: + msg316013
2018-05-01 19:38:56ned.deilysetnosy: + vinay.sajip
2018-05-01 19:37:24paulccreate