Search code examples
javalocalizationdate-formatting

How can I format day and month in the locale-correct order in Java?

Is there a way to format a day and month (in compact form), but not year, in the locale-correct order in Java/Kotlin? So for English it should be "Sep 20" but for Swedish "20 sep.".

For comparison, on Cocoa platforms, I can do the following (in Swift):

let formatter = DateFormatter()
formatter.locale = Locale(identifier: "sv_SE")
formatter.setLocalizedDateFormatFromTemplate("MMM d")
print(formatter.string(from: Date()))

This will correctly turn things around. Is there an equivalent thing to do with the Java SDKs? I've been trying various forms with both DateTimeFormatter and the older SimpleTimeFormat APIs, but no success.

Notes: Unlike this question, I don't want the full medium format that includes the year. I also don't want either DateTimeFormatter.ofPattern("MMM d"), since that gives the incorrect result in Swedish, or DateTimeFormatter.ofPattern("d MMM"), since that gives the incorrect result in English.

Solution

  • No, sorry. I know of no Java library that will automatically turn "MMM d" around into 20 sep. for a locale that prefers the day of month before the month abbreviation.

    You may try modifying the answer by Rowi in this way:

    DateTimeFormatter ft = 
    DateTimeFormatter
    .ofLocalizedDate(FormatStyle.MEDIUM)
    .withLocale(Locale.forLanguageTag("sv-SE"))
;

    However the result is:

    20 sep. 2019

    It includes the year, which you didn’t ask for.

    An advanced solution would use the DateTimeFormatterBuilder class to build DateTimeFormatter objects.

    DateTimeFormatterBuilder
.getLocalizedDateTimePattern(
    FormatStyle.MEDIUM, 
    null, 
    IsoChronology.INSTANCE, 
    Locale.forLanguageTag("sv-SE")
)

    This returns d MMM y. Modify this string to delete the y and the space before it. Note that in other languages the y may be yy, yyyy or u and may not come last in the string. Pass your modified format pattern string to DateTimeFormatter.ofPattern.

    It may be shaky. Even if you look through the format pattern strings for all available locales, the next version of CLDR (where the strings come from) might still contain a surprise. But I think it’s the best we can do. If it were me, I’d consider throwing an exception in case I can detect that the string from getLocalizedDateTimePattern doesn’t look like one I know how to modify.