SimpleDateFormat with German Locale – Java 8 vs Java 10+

by

I don’t say it’s a nice solution, but it seems to be a way through.

    Map<Long, String> dayOfWeekTexts = Map.of(1L, "Mo", 2L, "Di", 
            3L, "Mi", 4L, "Do", 5L, "Fr", 6L, "Sa", 7L, "So");
    Map<Long, String> monthTexts = Map.ofEntries(Map.entry(1L, "Jan"), 
            Map.entry(2L, "Feb"), Map.entry(3L, "Mär"), Map.entry(4L, "Apr"),
            Map.entry(5L, "Mai"), Map.entry(6L, "Jun"), Map.entry(7L, "Jul"),
            Map.entry(8L, "Aug"), Map.entry(9L, "Sep"), Map.entry(10L, "Okt"),
            Map.entry(11L, "Nov"), Map.entry(12L, "Dez"));

    DateTimeFormatter formatter = new DateTimeFormatterBuilder()
            .appendText(ChronoField.DAY_OF_WEEK, dayOfWeekTexts)
            .appendLiteral(' ')
            .appendText(ChronoField.MONTH_OF_YEAR, monthTexts)
            .appendPattern(" dd HH:mm:ss z Z yyyy")
            .toFormatter(Locale.GERMANY);

    String toParse = "Mo Aug 18 11:25:26 MESZ +0200 2014";
    OffsetDateTime odt = OffsetDateTime.parse(toParse, formatter);
    System.out.println(odt);
    ZonedDateTime zdt = ZonedDateTime.parse(toParse, formatter);
    System.out.println(zdt);

Output running on my Oracle JDK 10.0.1:

2014-08-18T11:25:26+02:00
2014-08-18T11:25:26+02:00[Europe/Berlin]

Then again, no nice solution may exist.

java.time, the modern Java date and time API, allows us to specify texts to use for fields for both formatting and parsing. So I exploit that for both day of week and for month, specifying the abbreviations without dot that were used with the old COMPAT or JRE locale data. I have used the Java 9 Map.of and Map.ofEntries for building the maps we need. If this is to work in Java 8 too, you must find some other way to populate the two maps, I trust you to do that.

If you do need an old-fashioned java.util.Date (likely in a legacy code base), convert like this:

    Date date = Date.from(odt.toInstant());
    System.out.println("As legacy Date: " + date);

Output in my time zone (Europe/Copenhagen, probably roughly agrees with yours):

As legacy Date: Mon Aug 18 11:25:26 CEST 2014

Suggestion for a strategy

I am thinking that if that were me, I’d consider proceeding this way:

  1. Wait. Set the relevant system property from within Java: System.setProperty("java.locale.providers", "COMPAT,CLDR"); so it won’t be forgot in any environment. The COMPAT locale data have been around since 1.0 (I believe, at least close), so a lot of code out there depends on it (not only yours). The name was changed from JRE to COMPAT in Java 9. To me this may sound like a plan to keep the data around for quite a while still. According to the early access documentation it will still be available in Java 11 (the next “long term support” Java version) and with no deprecation warning or the like. And should it be removed in some future Java version, you will probably be able to find out soon enough that you can deal with the problem before upgrading.
  2. Use my solution above.
  3. Use the locale service provider interface that Basil Bourque linked to. There is no doubt that this is the nice solution in case the COMPAT data should be removed some unknown time in the future. You may even be able to copy the COMPAT locale data into your own files so they can’t take them away from you, only check if there are copyright issues before you do so. The reason why I mention the nice solution last is you said you aren’t happy with having to set a system property in every possible environment where your program may run. As far as I can tell, using your own locale data through the locale service provider interface will still require you to set the same system property (only to a different value).

More Related Contents:

  1. How to resolve java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
  2. JDK dateformatter parsing DayOfWeek in German locale, java8 vs java9
  3. Optional orElse Optional in Java
  4. Observer is deprecated in Java 9. What should we use instead of it?
  5. How to apply Filtering on groupBy in java streams
  6. Stream.peek() method in Java 8 vs Java 9
  7. Parallel flatMap always sequential
  8. java.text.ParseException: Unparseable date: "Augu 16, 1979" [duplicate]
  9. When to use: Java 8+ interface default method, vs. abstract method
  10. Why does a Java method reference with return type match the Consumer interface?
  11. What is difference between Collection.stream().forEach() and Collection.forEach()?
  12. Convert java.time.LocalDate into java.util.Date type
  13. How to parse month full form string using DateFormat in Java?
  14. Java 8 default methods as traits : safe?
  15. Maximum size of a method in Java 7 and 8
  16. Find maximum, minimum, sum and average of a list in Java 8
  17. Reflections – Java 8 – invalid constant type
  18. DateTimeFormatter month pattern letter “L” fails
  19. Java streams lazy vs fusion vs short-circuiting
  20. Collectors.summingInt() vs mapToInt().sum()
  21. Mock Instant.now() without using Clock into Constructor or without Clock Object
  22. How to check if a Java 8 Stream is empty?
  23. Adding a line in a JavaFX chart
  24. How to use JDK without JRE in Java 11 [duplicate]
  25. LocalDate to java.util.Date and vice versa simplest conversion? [duplicate]
  26. Is mapToDouble() really necessary for summing a List with Java 8 streams?
  27. Is it possible to cast a Stream in Java 8?
  28. Implied anonymous types inside lambdas
  29. Creating String representation of lambda expression [duplicate]
  30. Spring 3.2.x with Java 8

Leave a Comment