Получить шаблон формата даты из текущей локали

Question

Я хотел бы получить текущий формат даты.Неформатированная дата, мне нужен такой формат, как MM/dd/yyyy или dd/MM/yyyy в зависимости от текущей локали.У меня есть проверка, которая проверяет, ввела ли пользователь правильную дату из ввода, настроенного для его страны.

DateFormat dateFormat = DateFormat.getDateInstance(DateFormat.SHORT, Locale.US);
String format = ((SimpleDateFormat)dateFormat).toPattern();
System.out.println(format); // M/d/yy

, как вы можете видеть выше, результат отличается от того, который я хотел бы видеть, я делаюНе понимаю, почему он возвращает этот формат вместо MM/dd/yyyy, в таком случае, есть идеи, как я могу получить шаблон для текущей локали?

Answer 1

tl; dr

LocalDate.parse( 
    input , 
    DateTimeFormatter.ofLocalizedDate( FormatStyle.SHORT )
                     .withLocale( Locale.sytemDefault() ) 
)
catch ( DateTimeParseException e ) { … }

Избегайте устаревших классов даты и времени

Во-первых, вы используете ужасные классы, которые были устаревшими несколько лет назад java.time классы, определенные в JSR 310.

Просто проанализируйте его

У меня есть проверка, которая проверяет, правильно ли пользователь ввел правильную дату из ввода, настроенного для его страны.

Вам не нужно знать формат заранее.Если вы хотите увидеть, вводил ли пользователь данные, соответствующие формату, ожидаемому текущим значением по умолчанию Locale, просто попробуйте выполнить синтаксический анализ.Если синтаксический анализ не выполняется, вы знаете, что ввод был неверным.

Класс DateTimeFormatter может автоматически определять локализованный формат, соответствующий конкретной локали.

Locale locale = Locale.sytemDefault() ;   
DateTimeFormatter formatter = DateTimeFormatter.ofLocalizedDate( FormatStyle.SHORT ).withLocale( locale ) ;
try 
{ 
    LocalDate localDate = LocalDate.parse( input , f ) ;
} catch ( DateTimeParseException e ) 
{
    … handle the situation of faulty input
}

На самом деле, вызов .withLocale здесь избыточен.Если вы не укажете языковой стандарт, неявно применяется текущее значение по умолчанию для JVM Locale.Я сделал код явным, как я вам и предлагаю, чтобы сделать наши намерения ясными и очевидными.

Альтернативы

Кто-то прокомментировал:

Итак, вы утверждаете, что в некоторых локалях встроенные форматы неверны?

Вы должны понимать, что локализация - сложная тема.Даже в пределах конкретной культуры могут отличаться мнения относительно того, какие соглашения подходят.

Имейте в виду, что в версии 9 Java, по крайней мере те реализации, использующие OpenJDK, переключали источник деталей локализации,OpenJDK теперь использует Unicode Consortium Common Locale Data Repository (CLDR) .Поэтому некоторые типы поведения и форматы могут отличаться от предыдущих версий.

Помимо всего этого, соглашения со временем меняются и развиваются.

Итог: попробуйте спросить пользователя, какой формат он предпочитает.Предложите список на выбор.Сохраните их желаемый формат в качестве настройки предпочтений.

Answer 2

Я считаю ваши требования противоречивыми и невозможными.В лучшем случае вы пытаетесь неправильно использовать встроенные локализованные форматы.

Если вы хотите локализованный формат для локали США, используйте DateTimeFormatterBuilder.getLocalizedDateTimePattern():

    String dateFormatPattern = DateTimeFormatterBuilder
            .getLocalizedDateTimePattern(FormatStyle.SHORT, null,
                    IsoChronology.INSTANCE, Locale.US);
    System.out.println(dateFormatPattern);

Вывод (проверенв JDK 11):

М / д / гг

Или с FormatStyle.MEDIUM вместо FormatStyle.SHORT:

МММ d, y

Если, с другой стороны, вы хотите MM/dd/yyyy, просто укажите это прямо:

    String dateFormatPattern = "MM/dd/yyyy";

Требование первого кода для получения второго результата не имеет смысла.Данные о региональных стандартах CLDR - лучшая попытка учесть ожидания каждой культуры, и, как говорит Бэзил Бурк, они обычно обсуждаются.Как правило, я рекомендую вам доверять CLDR, чтобы узнать ожидания разных культур лучше, чем вы сами, ведь они приложили усилия, которые вы никогда не сможете сделать самостоятельно.С другой стороны, вы лучше знаете своих пользователей, и нередко нам приходится жестко кодировать формат, отличный от встроенного, чтобы удовлетворить наших собственных пользователей.