Обходной путь
DateTimeFormatter dtf = new
DateTimeFormatterBuilder()
.appendPattern("yyyyMMddHHmmss")
.appendValue(ChronoField.MILLI_OF_SECOND,3)
.toFormatter()
Синтаксический анализ соседних значений обычно труден проблема. Он предназначен для обработки случая, когда первый элемент имеет переменную ширину (год), а все остальные элементы имеют фиксированную ширину (месяц, день и т. Д. c). Однако буква «S» - это дробная часть, а не значение. В частности, дробь может быть переменной ширины - более или менее трех цифр являются возможными вариантами. Учитывая общий случай переменной ширины года и переменной ширины миллисекунды, невозможно определить, какое из двух полей было предназначено для переменной.
Сказав это, реализация (и javado c ) не закончились, как я хотел. Описание «дроби» в DateTimeFormatter описывает действия в строгом и мягком режиме, но нет доступа к строгому или мягкому режиму при использовании DateTimeFormatter.ofPattern (). Это ошибка документации, которая должна быть исправлена путем удаления обсуждения строгого и снисходительного характера.
Хуже того, однако, что шаблон SSS, следовательно, в конечном итоге использовал строгий режим, когда подходящий режим будет подходящим. В настоящее время DateTimeFormatter.ofPattern ("hhmmss.SSS") требует трех цифр для миллисекунд, когда изначально предполагалось, что для этого требуется от 0 до 9 (мягкое поведение).
Я попытался изменить все DateTimeFormatter.ofPattern () метод, чтобы использовать мягкий анализ, и он не сломал тесты (что по-своему плохо). Это может быть допустимым исправлением, но только если оно включено в JDK 8, поскольку, когда люди адаптируются к строгому анализу, будет трудно сделать его снисходительным.
Учитывая, что текущая реализация требует три цифры для SSS, это поэтому очень удивительно, что разбор смежных значений не применяется.