A DESCRIPTION OF THE PROBLEM :
Provided `DateTimeFormatter` are all rather lenient. Say that I want to have something specific. I can use:
DateTimeFormatter strictDateTimeFormatter = new DateTimeFormatterBuilder()
.parseStrict()
.parseCaseSensitive()
.appendValue(YEAR, 4, 10, SignStyle.EXCEEDS_PAD)
.appendLiteral('-')
.appendValue(MONTH_OF_YEAR, 2)
.appendLiteral('-')
.appendValue(DAY_OF_MONTH, 2)
.appendLiteral('T')
.appendValue(HOUR_OF_DAY, 2)
.appendLiteral(':')
.appendValue(MINUTE_OF_HOUR, 2)
.appendLiteral(':')
.appendValue(SECOND_OF_MINUTE, 2)
.appendFraction(MILLI_OF_SECOND, 3, 3, true)
.appendOffsetId()
.optionalStart()
.appendLiteral('[')
.parseCaseSensitive()
.appendZoneRegionId()
.appendLiteral(']')
.toFormatter();
mostly it's just inlined formatters into this big one, removing all optionality, case insensitivity etc.
The interesting part is:
.appendFraction(MILLI_OF_SECOND, 3, 3, true)
so I want 3 digit millis, but with leading decimal separator. It works, but problem is, that it should not accept 1 or 2 digit fractions in input, only 3 digits should succeed. However in following samples:
"2017-12-01T14:12:45.1+01:00[Europe/Prague]"
"2017-12-01T14:12:45.12+01:00[Europe/Prague]"
"2017-12-01T14:12:45.123+01:00[Europe/Prague]"
"2017-12-01T14:12:45.1234+01:00[Europe/Prague]"
.12 and .123 succeeds.
I'm pretty convinced, that this is a bug, and in following code:
if (digit < 0) {
if (pos < minEndPos) {
return ~position; // need at least min width digits
}
pos--;
break;
}
the `pos--;` should happen before `if` or if should also test equality.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
see description.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
If I specify I want min 3 digits and max 3 digits, then only 3 digit frations should be OK.
ACTUAL -
2 and 3 digit fractions are accepted.
CUSTOMER SUBMITTED WORKAROUND :
probably only not using constructs leading to this method.
FREQUENCY : always
Provided `DateTimeFormatter` are all rather lenient. Say that I want to have something specific. I can use:
DateTimeFormatter strictDateTimeFormatter = new DateTimeFormatterBuilder()
.parseStrict()
.parseCaseSensitive()
.appendValue(YEAR, 4, 10, SignStyle.EXCEEDS_PAD)
.appendLiteral('-')
.appendValue(MONTH_OF_YEAR, 2)
.appendLiteral('-')
.appendValue(DAY_OF_MONTH, 2)
.appendLiteral('T')
.appendValue(HOUR_OF_DAY, 2)
.appendLiteral(':')
.appendValue(MINUTE_OF_HOUR, 2)
.appendLiteral(':')
.appendValue(SECOND_OF_MINUTE, 2)
.appendFraction(MILLI_OF_SECOND, 3, 3, true)
.appendOffsetId()
.optionalStart()
.appendLiteral('[')
.parseCaseSensitive()
.appendZoneRegionId()
.appendLiteral(']')
.toFormatter();
mostly it's just inlined formatters into this big one, removing all optionality, case insensitivity etc.
The interesting part is:
.appendFraction(MILLI_OF_SECOND, 3, 3, true)
so I want 3 digit millis, but with leading decimal separator. It works, but problem is, that it should not accept 1 or 2 digit fractions in input, only 3 digits should succeed. However in following samples:
"2017-12-01T14:12:45.1+01:00[Europe/Prague]"
"2017-12-01T14:12:45.12+01:00[Europe/Prague]"
"2017-12-01T14:12:45.123+01:00[Europe/Prague]"
"2017-12-01T14:12:45.1234+01:00[Europe/Prague]"
.12 and .123 succeeds.
I'm pretty convinced, that this is a bug, and in following code:
if (digit < 0) {
if (pos < minEndPos) {
return ~position; // need at least min width digits
}
pos--;
break;
}
the `pos--;` should happen before `if` or if should also test equality.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
see description.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
If I specify I want min 3 digits and max 3 digits, then only 3 digit frations should be OK.
ACTUAL -
2 and 3 digit fractions are accepted.
CUSTOMER SUBMITTED WORKAROUND :
probably only not using constructs leading to this method.
FREQUENCY : always
- relates to
-
JDK-8282946 JDK-8230136 not ported to Java 11
-
- Closed
-