Per LOGBACK-262 [1], logback does not conform to ISO8601 when printing %d{ISO8601}. We're in the process of fixing this [2], but we'd like to maintain backward compatibility for log parsers that might rely on the incorrect format. We have a couple options. OPTION 1. Add a new option for %d that enables the legacy incorrect format. Deprecate it, and remove it after several releases. Examples: %d{ISO8601_OLD} %d{NOT8601} %d{OLD8601} %d{ISO8601,,old} other? OPTION 2. Force users to specify a custom date format that matches the legacy incorrect format: %d{"yyyy-MM-dd HH:mm:ss,SSS"} Please provide feedback on these options (or a new one) by June 23. Thanks, Tony [1] http://jira.qos.ch/browse/LOGBACK-262 [2] https://github.com/qos-ch/logback/pull/207
Per LOGBACK-262 [1], logback does not conform to ISO8601 when printing %d{ISO8601}. We're in the process of fixing this [2], but we'd like to maintain backward compatibility for log parsers that might rely on the incorrect format. We have a couple options.
OPTION 1. Add a new option for %d that enables the legacy incorrect format. Deprecate it, and remove it after several releases. Examples:
%d{ISO8601_OLD} %d{NOT8601} %d{OLD8601} %d{ISO8601,,old} other?
OPTION 2. Force users to specify a custom date format that matches the legacy incorrect format:
%d{"yyyy-MM-dd HH:mm:ss,SSS"}
Please provide feedback on these options (or a new one) by June 23.
I would go for option one. Here is why: Make a pattern name HUMAN_ISO8601 to avoid people writing the pattern over again like in option two. The NO_T is valid as long as there is a mutual agreement among the participating parties. I have access to all ISO documents at work and can provide a citation (chapter, verbatim, etc.) if needed. Michael
Hello everyone, At present time, %d{ISO8601} is equivalent to writing %d{"yyyy-MM-dd HH:mm:ss,SSS"}. However, to match the ISO8601 standard the output should be that of %d{"yyyy-MM-dd'T'HH:mm:ss,SSS"}. Note the 'T' in the middle. On the other hand, there is also a necessity to maintain backward compatibility for log parsers that rely on the current albeit incorrect format. Thus, we are hesitating between two options Option 1) Introduce the constant ISO8601_OLD so that %d{ISO8601_OLD} is interpreted as equivalent to %d{"yyyy-MM-dd HH:mm:ss,SSS"} and *change* %d{ISO8601} so it is now equivalent to %d{"yyyy-MM-dd HH:mm:ss,SSS"}. Option 2) Keep %d{ISO8601} as equivalent to %d{"yyyy-MM-dd HH:mm:ss,SSS"} and *introduce* new constant ISO8601_STRICT so that %d{ISO8601_STRICT} is interpreted as equivalent to %d{"yyyy-MM-dd'T'HH:mm:ss,SSS"}. Personally, I favor the latter (option 2) as it preserves backward compatibility and allows users to easily refer to the correct ISO8601 format if they wish to do so. Indeed, writing %d{ISO8601_STRICT} is easier than %d{"yyyy-MM-dd'T'HH:mm:ss,SSS"}. Moreover, we can encourage the use of %d{ISO8601_STRICT} by favoring it in the documentation, e.g. by mentioning it more often. Note that writing just %d is equivalent to writing %d{ISO8601}. Thus, we can assume that for most user the output generated by %d is done using the default, i.e. the incorrect format, making the backward compatibility argument more potent. Cheers, -- Ceki On 6/17/2014 4:22, Tony Trinh wrote:
Per LOGBACK-262 [1], logback does not conform to ISO8601 when printing %d{ISO8601}. We're in the process of fixing this [2], but we'd like to maintain backward compatibility for log parsers that might rely on the incorrect format. We have a couple options.
OPTION 1. Add a new option for %d that enables the legacy incorrect format. Deprecate it, and remove it after several releases. Examples:
%d{ISO8601_OLD} %d{NOT8601} %d{OLD8601} %d{ISO8601,,old} other?
OPTION 2. Force users to specify a custom date format that matches the legacy incorrect format:
%d{"yyyy-MM-dd HH:mm:ss,SSS"}
Please provide feedback on these options (or a new one) by June 23.
Thanks, Tony
[1] http://jira.qos.ch/browse/LOGBACK-262 [2] https://github.com/qos-ch/logback/pull/207
Ceki, My vote is for option 1). The standard violating "no T" original format is a bug that should never have happened. I also vote for just %d to yield the correct (strict) ISO 8601 format. brent p.s. I am tempted to betray my regional preferences by also advocating for the second/millisecond decimal separator to be a '.' instead of a ','...
________________________________ From: Ceki Gülcü <ceki@qos.ch> To: logback-dev@qos.ch Sent: Tuesday, June 17, 2014 5:38 PM Subject: Re: [logback-dev] ISO8601 format
Hello everyone,
At present time, %d{ISO8601} is equivalent to writing %d{"yyyy-MM-dd HH:mm:ss,SSS"}. However, to match the ISO8601 standard the output should be that of %d{"yyyy-MM-dd'T'HH:mm:ss,SSS"}. Note the 'T' in the middle.
On the other hand, there is also a necessity to maintain backward compatibility for log parsers that rely on the current albeit incorrect format.
Thus, we are hesitating between two options
Option 1)
Introduce the constant ISO8601_OLD so that %d{ISO8601_OLD} is interpreted as equivalent to %d{"yyyy-MM-dd HH:mm:ss,SSS"} and *change* %d{ISO8601} so it is now equivalent to %d{"yyyy-MM-dd HH:mm:ss,SSS"}.
Option 2)
Keep %d{ISO8601} as equivalent to %d{"yyyy-MM-dd HH:mm:ss,SSS"} and *introduce* new constant ISO8601_STRICT so that %d{ISO8601_STRICT} is interpreted as equivalent to %d{"yyyy-MM-dd'T'HH:mm:ss,SSS"}.
Personally, I favor the latter (option 2) as it preserves backward compatibility and allows users to easily refer to the correct ISO8601 format if they wish to do so. Indeed, writing %d{ISO8601_STRICT} is easier than %d{"yyyy-MM-dd'T'HH:mm:ss,SSS"}. Moreover, we can encourage the use of %d{ISO8601_STRICT} by favoring it in the documentation, e.g. by mentioning it more often.
Note that writing just %d is equivalent to writing %d{ISO8601}. Thus, we can assume that for most user the output generated by %d is done using the default, i.e. the incorrect format, making the backward compatibility argument more potent.
Cheers, -- Ceki
On 6/17/2014 4:22, Tony Trinh wrote:
Per LOGBACK-262 [1], logback does not conform to ISO8601 when printing %d{ISO8601}. We're in the process of fixing this [2], but we'd like to maintain backward compatibility for log parsers that might rely on the incorrect format. We have a couple options.
OPTION 1. Add a new option for %d that enables the legacy incorrect format. Deprecate it, and remove it after several releases. Examples:
%d{ISO8601_OLD} %d{NOT8601} %d{OLD8601} %d{ISO8601,,old} other?
OPTION 2. Force users to specify a custom date format that matches the legacy incorrect format:
%d{"yyyy-MM-dd HH:mm:ss,SSS"}
Please provide feedback on these options (or a new one) by June 23.
Thanks, Tony
[1] http://jira.qos.ch/browse/LOGBACK-262 [2] https://github.com/qos-ch/logback/pull/207
_______________________________________________ logback-dev mailing list logback-dev@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-dev
The following is from ISO 8601:2004. A newer version may exist. 4.3.2 Complete representations "NOTE By mutual agreement of the partners in information interchange, the character [T] may be omitted in applications where there is no risk of confusing a date and time of day representation with others defined in this International Standard." 4.2.2.4 Representations with decimal fraction "If a decimal fraction is included, lower order time elements (if any) shall be omitted and the decimal fraction shall be divided from the integer part by the decimal sign specified in ISO 31-0, i.e. the comma [,] or full stop [.]. Of these, the comma is the preferred sign.” So the current implementation is not in violation of ISO 8601. Regarding the separator of fraction of second: both comma and full stop are legal. JodaTime and java.time (JSR310) are both using the full stop by default. Example: DateTimeFormatter.ISO_OFFSET_DATE_TIME.withZone(ZoneId.systemDefault()).format(Instant.now()) returns something like 2014-06-18T02:10:26.626+02:00 I’m in favor of full stop but that is just a matter of personal taste. Given that the current implementation isn’t actually in violation of ISO 8601 I’d just leave everything unchanged to prevent any compatibility issues. Some other things to consider: ISO 8601 is either 02:10:26.626+02:00 or 021026.626+0200 but not 02:10:26.626+0200 (i.e. colons between time but not between timezone offset) which is, to my knowledge, the best that SimpleDateFormat can provide. We can omit the timezone offset in our case (which implies the somewhat ambiguous “local timezone offset” of the computer executing the code) but be aware of this issue if somebody asks for explicit timezone offset information. It’s not easy to provide correctly without either Joda or JSR310. Cheers, Jörn. On 18. Juni 2014 at 00:12:11, Brent (yhbrent@yahoo.com) wrote:
Ceki,
My vote is for option 1).
The standard violating "no T" original format is a bug that should never have happened.
I also vote for just %d to yield the correct (strict) ISO 8601 format.
brent
p.s. I am tempted to betray my regional preferences by also advocating for the second/millisecond decimal separator to be a '.' instead of a ','...
________________________________ From: Ceki Gülcü To: logback-dev@qos.ch Sent: Tuesday, June 17, 2014 5:38 PM Subject: Re: [logback-dev] ISO8601 format
Hello everyone,
At present time, %d{ISO8601} is equivalent to writing %d{"yyyy-MM-dd HH:mm:ss,SSS"}. However, to match the ISO8601 standard the output should be that of %d{"yyyy-MM-dd'T'HH:mm:ss,SSS"}. Note the 'T' in the middle.
On the other hand, there is also a necessity to maintain backward compatibility for log parsers that rely on the current albeit incorrect format.
Thus, we are hesitating between two options
Option 1)
Introduce the constant ISO8601_OLD so that %d{ISO8601_OLD} is interpreted as equivalent to %d{"yyyy-MM-dd HH:mm:ss,SSS"} and *change* %d{ISO8601} so it is now equivalent to %d{"yyyy-MM-dd HH:mm:ss,SSS"}.
Option 2)
Keep %d{ISO8601} as equivalent to %d{"yyyy-MM-dd HH:mm:ss,SSS"} and *introduce* new constant ISO8601_STRICT so that %d{ISO8601_STRICT} is interpreted as equivalent to %d{"yyyy-MM-dd'T'HH:mm:ss,SSS"}.
Personally, I favor the latter (option 2) as it preserves backward compatibility and allows users to easily refer to the correct ISO8601 format if they wish to do so. Indeed, writing %d{ISO8601_STRICT} is easier than %d{"yyyy-MM-dd'T'HH:mm:ss,SSS"}. Moreover, we can encourage the use of %d{ISO8601_STRICT} by favoring it in the documentation, e.g. by mentioning it more often.
Note that writing just %d is equivalent to writing %d{ISO8601}. Thus, we can assume that for most user the output generated by %d is done using the default, i.e. the incorrect format, making the backward compatibility argument more potent.
Cheers, -- Ceki
On 6/17/2014 4:22, Tony Trinh wrote:
Per LOGBACK-262 [1], logback does not conform to ISO8601 when printing %d{ISO8601}. We're in the process of fixing this [2], but we'd like to maintain backward compatibility for log parsers that might rely on the incorrect format. We have a couple options.
OPTION 1. Add a new option for %d that enables the legacy incorrect format. Deprecate it, and remove it after several releases. Examples:
%d{ISO8601_OLD} %d{NOT8601} %d{OLD8601} %d{ISO8601,,old} other?
OPTION 2. Force users to specify a custom date format that matches the legacy incorrect format:
%d{"yyyy-MM-dd HH:mm:ss,SSS"}
Please provide feedback on these options (or a new one) by June 23.
Thanks, Tony
[1] http://jira.qos.ch/browse/LOGBACK-262 [2] https://github.com/qos-ch/logback/pull/207
_______________________________________________ logback-dev mailing list logback-dev@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-dev
_______________________________________________ logback-dev mailing list logback-dev@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-dev
Jörn wrote:
The following is from ISO 8601:2004. A newer version may exist...the character [T] may be omitted
I got my info from wikipedia: https://en.wikipedia.org/wiki/ISO_8601 You are right, the section on combining date and time https://en.wikipedia.org/wiki/ISO_8601#Combined_date_and_time_representation... now states the same thing at the end: "It is permitted to omit the 'T' character by mutual agreement". Hmm, I do not recall seeing that before. Oh well, live and learn... I was aware of the ',' versus '.' optionality, which is why I put it in a throw away p.s. comment. I should have explicitly stated that ',' does not violate the standard; like you, I was trying to say that I just prefer the style of '.'. brent
________________________________
4.3.2 Complete representations "NOTE By mutual agreement of the partners in information interchange, the character [T] may be omitted in applications where there is no risk of confusing a date and time of day representation with others defined in this International Standard."
4.2.2.4 Representations with decimal fraction "If a decimal fraction is included, lower order time elements (if any) shall be omitted and the decimal fraction shall be divided from the integer part by the decimal sign specified in ISO 31-0, i.e. the comma [,] or full stop [.]. Of these, the comma is the preferred sign.”
So the current implementation is not in violation of ISO 8601.
Regarding the separator of fraction of second: both comma and full stop are legal. JodaTime and java.time (JSR310) are both using the full stop by default.
Example: DateTimeFormatter.ISO_OFFSET_DATE_TIME.withZone(ZoneId.systemDefault()).format(Instant.now()) returns something like 2014-06-18T02:10:26.626+02:00
I’m in favor of full stop but that is just a matter of personal taste.
Given that the current implementation isn’t actually in violation of ISO 8601 I’d just leave everything unchanged to prevent any compatibility issues.
Some other things to consider: ISO 8601 is either 02:10:26.626+02:00 or 021026.626+0200 but not 02:10:26.626+0200 (i.e. colons between time but not between timezone offset) which is, to my knowledge, the best that SimpleDateFormat can provide. We can omit the timezone offset in our case (which implies the somewhat ambiguous “local timezone offset” of the computer executing the code) but be aware of this issue if somebody asks for explicit timezone offset information. It’s not easy to provide correctly without either Joda or JSR310.
Cheers, Jörn.
On 18. Juni 2014 at 00:12:11, Brent (yhbrent@yahoo.com) wrote:
Ceki, My vote is for option 1). The standard violating "no T" original format is a bug that should never have happened. I also vote for just %d to yield the correct (strict) ISO 8601 format. brent p.s. I am tempted to betray my regional preferences by also advocating for the second/millisecond decimal separator to be a '.' instead of a ','...
________________________________ From: Ceki Gülcü To: logback-dev@qos.ch Sent: Tuesday, June 17, 2014 5:38 PM Subject: Re: [logback-dev] ISO8601 format
Hello everyone,
At present time, %d{ISO8601} is equivalent to writing %d{"yyyy-MM-dd HH:mm:ss,SSS"}. However, to match the ISO8601 standard the output should be that of %d{"yyyy-MM-dd'T'HH:mm:ss,SSS"}. Note the 'T' in the middle.
On the other hand, there is also a necessity to maintain backward compatibility for log parsers that rely on the current albeit incorrect format.
Thus, we are hesitating between two options
Option 1)
Introduce the constant ISO8601_OLD so that %d{ISO8601_OLD} is interpreted as equivalent to %d{"yyyy-MM-dd HH:mm:ss,SSS"} and *change* %d{ISO8601} so it is now equivalent to %d{"yyyy-MM-dd HH:mm:ss,SSS"}.
Option 2)
Keep %d{ISO8601} as equivalent to %d{"yyyy-MM-dd HH:mm:ss,SSS"} and *introduce* new constant ISO8601_STRICT so that %d{ISO8601_STRICT} is interpreted as equivalent to %d{"yyyy-MM-dd'T'HH:mm:ss,SSS"}.
Personally, I favor the latter (option 2) as it preserves backward compatibility and allows users to easily refer to the correct ISO8601 format if they wish to do so. Indeed, writing %d{ISO8601_STRICT} is easier than %d{"yyyy-MM-dd'T'HH:mm:ss,SSS"}. Moreover, we can encourage the use of %d{ISO8601_STRICT} by favoring it in the documentation, e.g. by mentioning it more often.
Note that writing just %d is equivalent to writing %d{ISO8601}. Thus, we can assume that for most user the output generated by %d is done using the default, i.e. the incorrect format, making the backward compatibility argument more potent.
Cheers, -- Ceki
On 6/17/2014 4:22, Tony Trinh wrote:
Per LOGBACK-262 [1], logback does not conform to ISO8601 when printing %d{ISO8601}. We're in the process of fixing this [2], but we'd like to maintain backward compatibility for log parsers that might rely on the incorrect format. We have a couple options.
OPTION 1. Add a new option for %d that enables the legacy incorrect format. Deprecate it, and remove it after several releases. Examples:
%d{ISO8601_OLD} %d{NOT8601} %d{OLD8601} %d{ISO8601,,old} other?
OPTION 2. Force users to specify a custom date format that matches the legacy incorrect format:
%d{"yyyy-MM-dd HH:mm:ss,SSS"}
Please provide feedback on these options (or a new one) by June 23.
Thanks, Tony
[1] http://jira.qos.ch/browse/LOGBACK-262 [2] https://github.com/qos-ch/logback/pull/207
_______________________________________________ logback-dev mailing list logback-dev@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-dev
_______________________________________________ logback-dev mailing list logback-dev@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-dev
_______________________________________________ logback-dev mailing list logback-dev@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-dev
Am 2014-06-18 00:08, schrieb Brent:
Ceki,
My vote is for option 1).
The standard violating "no T" original format is a bug that should never have happened.
I also vote for just %d to yield the correct (strict) ISO 8601 format.
+1, absolutely.
p.s. I am tempted to betray my regional preferences by also advocating for the second/millisecond decimal separator to be a '.' instead of a ','...
________________________________ From: Ceki Gülcü <ceki@qos.ch> To: logback-dev@qos.ch Sent: Tuesday, June 17, 2014 5:38 PM Subject: Re: [logback-dev] ISO8601 format
Hello everyone,
At present time, %d{ISO8601} is equivalent to writing %d{"yyyy-MM-dd HH:mm:ss,SSS"}. However, to match the ISO8601 standard the output should be that of %d{"yyyy-MM-dd'T'HH:mm:ss,SSS"}. Note the 'T' in the middle.
On the other hand, there is also a necessity to maintain backward compatibility for log parsers that rely on the current albeit incorrect format.
Thus, we are hesitating between two options
Option 1)
Introduce the constant ISO8601_OLD so that %d{ISO8601_OLD} is interpreted as equivalent to %d{"yyyy-MM-dd HH:mm:ss,SSS"} and *change* %d{ISO8601} so it is now equivalent to %d{"yyyy-MM-dd HH:mm:ss,SSS"}.
Option 2)
Keep %d{ISO8601} as equivalent to %d{"yyyy-MM-dd HH:mm:ss,SSS"} and *introduce* new constant ISO8601_STRICT so that %d{ISO8601_STRICT} is interpreted as equivalent to %d{"yyyy-MM-dd'T'HH:mm:ss,SSS"}.
Personally, I favor the latter (option 2) as it preserves backward compatibility and allows users to easily refer to the correct ISO8601 format if they wish to do so. Indeed, writing %d{ISO8601_STRICT} is easier than %d{"yyyy-MM-dd'T'HH:mm:ss,SSS"}. Moreover, we can encourage the use of %d{ISO8601_STRICT} by favoring it in the documentation, e.g. by mentioning it more often.
Note that writing just %d is equivalent to writing %d{ISO8601}. Thus, we can assume that for most user the output generated by %d is done using the default, i.e. the incorrect format, making the backward compatibility argument more potent.
Cheers, -- Ceki
On 6/17/2014 4:22, Tony Trinh wrote:
Per LOGBACK-262 [1], logback does not conform to ISO8601 when printing %d{ISO8601}. We're in the process of fixing this [2], but we'd like to maintain backward compatibility for log parsers that might rely on the incorrect format. We have a couple options.
OPTION 1. Add a new option for %d that enables the legacy incorrect format. Deprecate it, and remove it after several releases. Examples:
%d{ISO8601_OLD} %d{NOT8601} %d{OLD8601} %d{ISO8601,,old} other?
OPTION 2. Force users to specify a custom date format that matches the legacy incorrect format:
%d{"yyyy-MM-dd HH:mm:ss,SSS"}
Please provide feedback on these options (or a new one) by June 23.
Thanks, Tony
[1] http://jira.qos.ch/browse/LOGBACK-262 [2] https://github.com/qos-ch/logback/pull/207
_______________________________________________ logback-dev mailing list logback-dev@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-dev
_______________________________________________ logback-dev mailing list logback-dev@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-dev
Am 2014-06-17 23:38, schrieb Ceki Gülcü:
Hello everyone,
At present time, %d{ISO8601} is equivalent to writing %d{"yyyy-MM-dd HH:mm:ss,SSS"}. However, to match the ISO8601 standard the output should be that of %d{"yyyy-MM-dd'T'HH:mm:ss,SSS"}. Note the 'T' in the middle.
On the other hand, there is also a necessity to maintain backward compatibility for log parsers that rely on the current albeit incorrect format.
That argument does count "maintain backward compatibility" because Logback broke it already several times in a patch version: 1.1.2: Removed deprecated constructors in SocketAppender and related classes. 1.0.7: Groovy and Janino upgrade 1.0.2: By default PatternLayout will now output its pattern at the top of log files and so forth, so it is a lousy argument. Michael
Hi Michael, On 6/18/2014 8:10, Michael Osipov wrote:
That argument does count "maintain backward compatibility" because Logback broke it already several times in a patch version:
1.1.2: Removed deprecated constructors in SocketAppender and related classes. 1.0.7: Groovy and Janino upgrade 1.0.2: By default PatternLayout will now output its pattern at the top of log files
and so forth, so it is a lousy argument.
Right. I am not advocating backward compatibility as an absolute principle which can never be infringed. There are occasions where backward compatibility needs to abandoned in light of other considerations. Let me respond to the examples you brought up where compatibility was broken:
1.1.2: Removed deprecated constructors in SocketAppender and related classes.
IMO, the code in SocketAppender needs to be partially re-written to make it less confusing. I'd expect much heavier changes there in the future.
1.0.7: Groovy and Janino upgrade
When a component that logback optionally depends on, e.g Janino, breaks compatibility, there is no alternative that can keep everyone happy in every case. No later than as yesterday, I was bitten by the Janino issue in a client project. My project relies on logback 1.1.3 for logging and on Janino 2.5 to perform certain computations. In order to enable logback features requiring Janino (version 2.6), I had to adapt parts of the project code to use Janino 2.6 (instead of 2.5). Luckily, the required changes were not too extensive *and* the affected code was under the control of my team. The problem would have become unsolvable otherwise. Had logback not upgraded to Janino 2.6 and stayed with 2.5, the compatibility problem would have been just as bad if my client project depended on Janino 2.6 (instead of 2.5).
1.0.2: By default PatternLayout will now output its pattern at the top of log files
The sentence "By default PatternLayout will now output..." is in the release notes [1] of version 1.0.2 dated 2012-04-26. However, the sentence that _just_ follows it, states: This feature, although still available, is no longer enabled by default. See release notes for version 1.0.3 for details. In 1.0.2, it was decided to add by default a comment at the top each log file in order to help with the parsing. After the release of 1.0.2, several people complained about the change. See http://jira.qos.ch/browse/LOGBACK-201 A survey was created to request user input. It appeared that a majority of the users preferred not to enable by default printing of the pattern as the first line in the log files. Bowing to popular demand, the compatibility breaking change was *reverted* in 1.0.3. It seems to me that the ISO8601-related case bears many resemblances to LOGBACK-201. Cheers, [1] http://logback.qos.ch/news.html
Michael
-- Ceki
participants (5)
-
Brent -
Ceki Gülcü -
Jörn Huxhorn -
Michael Osipov -
Tony Trinh