-
Notifications
You must be signed in to change notification settings - Fork 41.2k
To fully align with ISO-8601, use yyyy-MM-dd'T'HH:mm:ss.SSSXXX as the default logging date format #28654
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
No timezones, offsets only. One should not use |
As I understand it, Flagging for team meeting so that we can discuss whether we want to make this change, and if we do, the timing of it. It feels like something that should possibly wait until 3.x to me. |
@wilkinsona , please use |
@Mahoney Please change the issue title accordingly. |
OK, I'm sold on |
Told you ;-) |
If we're going to add an offset, I wonder if we should go one step further and also use the Our current format produces timestamps like the following:
Adding an offset would change this to the following:
Fully aligning with ISO-8601 would change this to the following:
|
@wilkinsona Yes, please do so. ISO 8601 clearly says (if you have access to the document): the 'T' can be replaced with a space only if a mutual agreement has been done between parties. Same mistake was done in Git and they have 'corrected' with |
We've discussed this today and we're going to add the |
At present the default logging pattern does not append any timezone / offset information to the time of the event. This makes it impossible to parse back into an instant reliably (e.g. when using a log exporter to push a docker container's stdout to elasticsearch or similar), because the timezone will be system / system property dependent.
Should just be a matter of adding
XXX
to the end of the default forLOG_DATEFORMAT_PATTERN
inorg/springframework/boot/logging/logback/defaults.xml
&org.springframework.boot.logging.logback.DefaultLogbackConfiguration
.A good test is that the result is parseable by
ZonedDateTime.parse
. See DateConverterSpec which shows onlyXXX
reliably produces a parseable ISO 8601 string.The text was updated successfully, but these errors were encountered: