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.
Would be extreme useful for lot of multi-lingual apps to see this idea implemented.
@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:
6/19/2019, 9:43 AMinstead of
6/19/2019 9:43 AM).
formatDateTimeas well as
toStringthat are called on a
MendixDateTimeobject using a default pattern might return a different result.
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.
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'.