| msg316012 - (view) |
Author: Paul Cyr (paulc) |
Date: 2018-05-01 19:37 |
| From the docs: https://docs.python.org/3.6/library/logging.html#logging.Formatter "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: 2018-05-01T19:04:31,505Z 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) *  |
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 https://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representations |
|
|
| msg316185 - (view) |
Author: Vinay Sajip (vinay.sajip) * |
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) https://github.com/python/cpython/commit/c4994dc00d9828a99510f3851da93b0e1c18361d |
|
|
| msg316187 - (view) |
Author: Vinay Sajip (vinay.sajip) * |
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) https://github.com/python/cpython/commit/eb5abdc70815c4207829551ede4a7dc302d56c19 |
|
|
| msg316662 - (view) |
Author: Paul Ganssle (p-ganssle) * |
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: YYYY-MM-DD HH:MM:SS,mmm 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) * |
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) * |
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) * |
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) https://github.com/python/cpython/commit/eb8516becc267caeb0ca6f9c41e805d1ba1caaa3 |
|
|
| msg317842 - (view) |
Author: Vinay Sajip (vinay.sajip) * |
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 , 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) * |
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: https://tools.ietf.org/html/rfc3339 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) * |
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) * |
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) https://github.com/python/cpython/commit/23cee80cfade1a9019c52b3a17d8e5c1b5db17e2 |
|
|
| msg318444 - (view) |
Author: Vinay Sajip (vinay.sajip) * |
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) https://github.com/python/cpython/commit/4b6691e40f004bf3a08b1843620f5f6028d2b79d |
|
|
| msg318445 - (view) |
Author: Vinay Sajip (vinay.sajip) * |
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) https://github.com/python/cpython/commit/461ad598d12eba7754181402e00bb7cfc7f1d9cf |
|
|