tl;dr

Do not be concerned. Just perform a check that your typical date-time formatted text generated by DateTimeFormatter meets the expectations of your users in whatever locales you support. If so, no need to involve that ICU library from IBM.

Let java.time automatically localize text representing date-time values.

ZoneId ZoneId = ZoneId.of( "America/Montreal" ) ;
Locale locale = Locale.CANADA_FRENCH ;
ZonedDateTime zdt = ZonedDateTime.now( zoneId ) ;
DateTimeFormatter formatter = DateTimeFormatter.ofLocalizedDateTime( FormatStyle.FULL ).withLocale( locale ) ;
String output = zdt.format( formatter ) ;

Details

FYI, that Sonar message refers to when Unicode CLDR became the default locale resource in Java implementations based on OpenJDK for Java 9 and later. See JEP 252: Use CLDR Locale Data by Default. Java 10 brought further support.

You said:

I am quite unsure what is the current problem (code working fine so far).

I believe this is not a question of code working.

The issue is localization being true to a locale.

Formatting of date-time values vary greatly by human language, culture, and sub-cultures. We are talking about translated words, and rules for punctuation, abbreviation, ordering of elements, capitalization, and so on. Tracking all this localization information involves much data. And on top of that, they change. Cultures change, and academics’ understanding changes.

The implementation of such locale data used by default in OpenJDK for Java 8 and earlier was relatively limited and shallow, without coverage of many sub-cultures.

In contrast, the CLDR managed by the Unicode Consortium is vast and detailed, covering many sub-cultures. Earlier version of OpenJDK contained a copy of the CLDR. But only in Java 9 did it become the default locale resource, with lookups done there first.

Perhaps the Sonar message is saying that java.time.DateTimeFormatter has some problems with particular sub-cultures’ nuances. But I have not heard of any. You could check the OpenJDK issue tracker, if you are concerned.

➥ I would not be worried. If you know your app will be used for only a few specific locales, test those locales. Recruit a panel of users from each of those locales. See if typical output from your app meets their expectations. If they are satisfied, write some unit tests, and call it a day.

Keep in mind that, as I said, the cultural norms change over time. The Unicode consortium tracks those changes, emitting new versions of the CLDR as needed. When you update your Java implementation, you may be getting an updated version of the CLDR. It is quite possible that some day in some locale you may get a different output when generating text representing a date-time. If you might care about such variations, write those unit tests I mentioned above.

FYI, the library mentioned by the Sonar message is a Java implementation of International Components for Unicode (ICU) built by Taligent and IBM, now housed at the Unicode Consortium: http://site.icu-project.org/

Basil Bourque already wrote the wise answer. I am humbly adding a modest supplement.

SonarQube is right and wrong.

• The message you got is correct that DateTimeFormatter.ofPattern("yyyy-MM-dd-HH-mm-ss") will not produce a format that will make users across many languages and cultures happy. Said without knowing whether this was ever your goal.
• The message is wrong about suggesting dtpg.getBestPattern("MMM dd, YYYY, h:mm A") since the code will crash with a java.lang.IllegalArgumentException: Illegal pattern character 'A' or some other exception.

The code that the message refers to as non-compliant produces:

• 2020-12-31 on Java 8
• 2020年12月31日 on Java 11

So without knowing more than I can read in Basil Bourque’s answer it would seem to me that the SonarQube rule is an outdated one that had validity for Java 8, but that you should ignore for Java 11.

I suggest

The right way to go depends a lot on what you are formatting the date and time for.

• If for displaying to the user, there are a couple of options:

  • The shortcut is to use code similar to what the SonarQube message refers to as non-compliant for Java 8 since a lot of programmers have good experiences from it and it seems to be compliant in later Java versions.
  • The gold-plated solution is to ask your users which format they prefer and give them that.

• If for exchange with another system:

  • Preferably educate the developers of that other system to accept ISO 8601 format. Then just use Instant.toString() or OffsetDateTime.toString) since these methods produce ISO 8601.
  • If that other system needs the format that your existing code gives them, you have no choice: stick to the formatter that you have already got.

• If for storage: Prefer to store data-time objects rather than strings. For example use the timestamp with time zone or datetime datatype of your database engine and/or have your Hibernate 5 save an Instant or other date-time object.

Code analysers

TL;DR: Code analysers can certainly help us find bugs and other inadequacies in our code. They certainly also come with some false positives.

I do put some trust in code analysers. I haven’t got any experience with SonarQube. I am a happy SpotBugs user. I also selectively tell SpotBugs to ignore some rule in some method that I have written when I have convinced myself that the code stands the way I want it to. I am pretty convinced that I would do the same with SonarQube.