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_representations
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 ([email protected]) 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: [email protected]
>> >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
>> >[email protected]
>> >http://mailman.qos.ch/mailman/listinfo/logback-dev
>> >
>> >
>> >_______________________________________________
>> logback-dev mailing list
>> [email protected]
>> http://mailman.qos.ch/mailman/listinfo/logback-dev
>
>
>_______________________________________________
>logback-dev mailing list
>[email protected]
>http://mailman.qos.ch/mailman/listinfo/logback-dev
>
>_______________________________________________
logback-dev mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/logback-dev
