Luxon formats date different serverside then on the client

[FelixL]

Describe the problem/error/question

When Executing the Workflow in the Browser, it shows the expected formatted date:

in the mail, the date gets formatted like this:

shortened Workflow:

Information on your n8n setup

• n8n version: 0.224.2
• Database (default: SQLite): MySQL
• n8n EXECUTIONS_PROCESS setting (default: own, main): own
• Running n8n via (Docker, npm, n8n cloud, desktop app):Docker
• Operating system: ubuntu 22.04

[giulioandreini]

Hi @FelixL,
it looks like toLocaleString is influenced by the browser but also the server location and language settings when the nodes are executed. This is why you see different results.

To force it to a specified language you can use .setLocale('de'): this will tell toLocaleString to create a human-readable string with the German formatting.

So the correct expression is:

{{ DateTime.fromFormat( $json.due_date + " " + $json.due_time, "yyyy-MM-dd HH:mm").setZone('Europe/Vienna').setLocale('de').toLocaleString({month: 'long', day: 'numeric', year: 'numeric', hour: 'numeric', minute: '2-digit'}) }}

This will return: 25. Mai 2023 um 13:00

As an alternative you can also manually build your date format using the toFormat method provided by Luxon:

{{ DateTime.fromFormat( $json.due_date + " " + $json.due_time, "yyyy-MM-dd HH:mm").setZone('Europe/Vienna').toFormat('dd. LLL yyyy') }} um {{ DateTime.fromFormat( $json.due_date + " " + $json.due_time, "yyyy-MM-dd HH:mm").setZone('Europe/Vienna').toFormat('HH:mm') }}

This will return: 25. May 2023 um 13:00
Slight difference: in this case the name of the month is in English.

Please find a demo workflow with the examples here:

Hope it helps,
let me know if you need more support
Best

[pemontto]

And if you want the backend to be predictable you can add these environment variables. Unfortunately I’ve forgotten which one is actually required:

# Language and Locale settings for time formatting mainly
LANG=en_AU.UTF-8
LANGUAGE=en_AU
LC_ALL=en_AU.UTF-8

[FelixL]

@giulioandreini thanks for the detailed explanation, now it totally makes sense why this is happening

@pemontto thanks for those env variables, good to know there is a solution for the whole instance
Will try them later – do not want to break any running workflows which maybe depend on English formatted dates right now.