I guess this is sort of a bug report but more than anything is a gotcha warning and a reminder to myself about using the

setLocale()

and the locale aware formatting functions

lsnumberformat()

and

lsdateformat()

within parallel execution loops such as arrayEach() etc. This is the sort of thing you might want to do to speed up the sending of email messages with HTTP calls to an API where the connection overhead is quite significant. eg. Something along these lines.

parallel = true;
maxThread = 5;
arrayEach(messages, function(messagedata) {
  setLocale(messagedata.locale);
  // Generate and send a localised message here
  var payload = {
    message:"My message was sent on #lsdateformat(now(), "dddd d mmmm yyy")#"
  };
  // Send the message...
  var req = new Http(method:"POST", url:some_endpoint);
  req.addParam(type:"body", value:serializeJson(body));
  resp = req.send().getPrefix();
}, parallel, maxThreads);

The issue is that the

setLocale()

in your loop has a high chance of clobbering the locale value set by other loops. So when you use

lsdateformat()

or

lsnumberformat()

you can't be sure what locale you will get. The solution to to use the 3rd argument and pass the locale value into those functions. eg. use

lsdateformat(now(), "dddd d mmmm yyyy", "es")

It's more laborious but seems to solve the issue. I have a gist here showing the issue.

I would guess that this is an expected behaviour, docs say: Sets the country/language locale for CFML processing and the page returned to the client

Yes I agree but it doesn't stop it biting you hard when you try to use parallel execution to speed things up 😁