Add locale as optional parameter to formatDateTime(UTC) functions - Mendix Forum

Add locale as optional parameter to formatDateTime(UTC) functions

23

While working on an application with no English users (and thus no English UI) but integration with external API's in English, I found out that formatDateTime(UTC) has no way of defining an optional locale. This means that de default project locale is used as locale in microflows run in the system context.

So when I try to convert a date to a string I get for example: "5 mrt 2018 11:10:27 GMT”, which the API I'm talking to doesn't understand as it's expecting "5 mar 2018 11:10:27 GMT” for the same DateTime value.

Mendix does support locale as an optional parameter for formatDecimal, and the Java SimpleDateFormat (on which formatDateTime is based) also supports it. So I'd like the locale to also be available as a parameter for formatDateTime.

asked
4 answers

Would be extreme useful for lot of multi-lingual apps to see this idea implemented.

Created

@Bram, this idea does not solve your problem I guess. If formatDateTime would have accepted an optional local like nl_NL, you would still get "aug.” instead of "aug”, because of the breaking change since Mx8:
 

  • We are now using a newer version of CLDR specifications (release 33) for representing dates and numbers. Starting with Java 9, the JVM prefers CLDR locales over built-in JRE ones. We are using Java 11 starting with Mendix 8.0.0, so this means that some locales will have different configurations (for example, date time formatting). Here are a few examples of the changes you can expect:
    • Some locales now format dates with a comma between the date and time (for example, 6/19/2019, 9:43 AM instead of 6/19/2019 9:43 AM).
    • Some locales now add a period at the end of an abbreviation (for example, jan. instead of jan, or mon. instead of mon).
    • Where previously we only had a subset of locales (for example, just a single one for all Arabic locales), we now have specific ones (as in, for different Arabic regions).
    • In microflow expressions, functions like formatDateTime as well as toString that are called on a MendixDateTime object using a default pattern might return a different result.
Created

Currently this causes a big problem for the project I'm on: we've migrated from Mx 7 → 9 and now we’re running into various errors. The biggest one is dat “MMM” now adds a period (so “aug.” instead of “aug”) in the  nl_NL-locale. This is a problem when generating file names and CSV-files.

Created

Would be great if the optional locale can be added to the parseDateTime[UTC] functions too.

That would make it easier to parse datetime like "Tue Sep 12 22:18:36 CEST 2017” when running App in Dutch language (which does not recognize the “Tue” part) using 'EEE MMM d HH:mm:ss z yyyy'.

Created