[logback-dev] ISO8601 format

[Jörn Huxhorn]

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 at 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 at 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 at qos.ch
> >http://mailman.qos.ch/mailman/listinfo/logback-dev
> >
> >
> >_______________________________________________
> logback-dev mailing list
> logback-dev at qos.ch
> http://mailman.qos.ch/mailman/listinfo/logback-dev