n8n sends an ISO date like 2026-09-29T13:30:00.000Z in a message

Test record: found by Fractional HQ by reading the build on 29 October 2026, then checked on 11 November 2026 on n8n 2.23.4. The phone check is execution 94337 and the misspelt timezone is execution 94150, a replay of a real message. The format string was checked against the Luxon library in the n8n 2.38.1 image. Not tested: languages other than English.

Symptom

On 29 October 2026 we found that the 24 September build of our WhatsApp booking template wrote its confirmation message with a field called candidateSlotStart as it stood. That field was made with toUTC().toISO(). A booking for 14:30 in British Summer Time would therefore have read "2026-09-29T13:30:00.000Z" in the customer's chat, which is hard to read and also shows the hour in UTC, one hour off what the customer asked for.

Why it happens

We keep times in UTC inside the workflow, and comparing calendar slots depends on it. The fault was using the stored value as the displayed value. Nothing in n8n formats a date for you when it lands inside a text field, so the ISO string goes out as it is.

The fix that held

We format the time at the point where the message is written, in the business's own timezone:

DateTime.fromISO(x).setZone(tz).toFormat("cccc d LLLL 'at' HH:mm")

Here x is the stored UTC time and tz is a zone name such as Europe/London. We checked that format string against the Luxon library shipped in the n8n 2.38.1 image. The rule we took from it is that a test has to assert the text of the message, since a check that the send node ran would pass with any text at all.

On 11 November 2026 we sent a booking from a real phone to the current version of the template, and the reply read "You are booked in for Monday 16 November at 10:00. See you then!"

A guard that goes with it

The zone name comes from a cell in the clinic's row, and a typing mistake there would shift every time. In a replay of a real message we set that cell to "Europe/Lodnon" on purpose. The workflow sent the customer nothing and posted an alert in the owner's fallback channel that named the bad cell and suggested a name like Europe/London.

How we found it

We found the ISO string by reading the build on 29 October. The phone check is execution 94337, and the misspelt timezone is execution 94150, a replay of a real message with the text changed. Both are from the run of 11 November on n8n 2.23.4.

What we did not establish

We have no record of whether a customer ever received the ISO version, so we do not claim that one did. The format string gives day and month names in English, and we did not test other languages. In a replay of a real message, a 09:00 booking for a clinic on Paris time was stored as 08:00 UTC, which is correct, but we did not record the text of that confirmation.

Written by Fractional HQ from its own runs. If your n8n behaves differently, email hello@fractionalhq.uk and we will correct the note.