n8n Date Formatting: A Pre-Write Exercise

By Roman Rodomansky·Published 16 Oct 2026

Practise n8n date formatting with declared input formats, a review branch and UTC instant checks, stopping at a proposed write payload.

• n8n
• Data transformation
• Workflow debugging
• Exercise

Checked against the cited sources on 16 Oct 2026.

Your n8n date formatting exercise

This editorial exercise asks you to build an n8n date formatting workflow that preserves original inputs, parses declared formats, routes unresolved records for review and prepares approved timestamps for a proposed business-system write. n8n’s documentation recommends explicit Luxon parsing because dates pass between nodes as strings. The exercise is based on documentation; it has not been executed or validated.

Use your own n8n environment, JavaScript expressions and synthetic records. Define each input’s format, locale, source zone and meaning: instant or calendar date. This exercise processes instants only. No destination system or field contract is specified, so stop before any live write; stored-value verification, date-only destination semantics, future local-time scheduling and database time-zone-rule updates are outside scope.

The supplied n8n documentation establishes no edition or version. Check expression support in your environment before proceeding. We think making the input contract explicit is more useful than collecting formatting snippets: it forces the important interpretation decisions into the open.

Sources: n8n-docs/docs/build/work-with-data/handle-special-data-types/work-with-dates-and-times.md at main · n8n-io/n8n-docs · GitHub

Prepare inputs with expected dispositions

Use the following suggested editorial fixtures. The two America/New_York transition records are deliberately unresolved exercise inputs using the historical cases in Luxon’s zone guide: a skipped local time and a repeated local time. Keep both on the Review route. The guide explains that missing spring-forward times can advance and fall-back times can repeat; parsing validity alone does not settle the intended wall time or occurrence.

Sources: luxon/docs/parsing.md at master · moment/luxon · GitHub, luxon/docs/zones.md at master · moment/luxon · GitHub

n8n: Parse a date and preserve the evidence

When practising how to parse a date in n8n, keep the raw value beside its interpretation. Edit Fields can create or overwrite fields. Use it to retain rawDate, declaredFormat, locale, sourceZone and meaning; these field names are editorial choices. Then apply this suggested sequence.

1. Retain the untouched input and its declared contract.
2. Parse ISO strings with DateTime.fromISO(rawDate, { zone: sourceZone }).
3. Parse contracted custom strings with DateTime.fromFormat(rawDate, declaredFormat, { zone: sourceZone, locale: locale }).
4. Record isValid and invalidReason before attempting serialization.
5. For parsing failures, inspect DateTime.fromFormatExplain with the same input, format and options.

Luxon 3.7.2 documents the fromISO zone option as supplying the interpretation when an input has no offset; that reference does not establish the Luxon version bundled with your n8n instance. Do not infer automatic ambiguity detection from the supplied materials: the zone guide and versioned API index cover it differently.

Sources: n8n-docs/docs/build/work-with-data/handle-special-data-types/work-with-dates-and-times.md at main · n8n-io/n8n-docs · GitHub, luxon/docs/parsing.md at master · moment/luxon · GitHub, luxon 3.7.2 | Documentation, n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.set.md at main · n8n-io/n8n-docs · GitHub

Route unresolved records before formatting

Create a suggested approval flag requiring both a valid parse and resolved interpretation. Use the If node’s documented comparison branching to separate approved records from review records. Missing source zones, undeclared slash-date conventions and unresolved transition fixtures belong on the review branch. Keep that branch disconnected from the proposed write path and retain a specific review reason.

For approved records, practise n8n date formatting. The supplied community documentation mirror describes From Date Format for unrecognized inputs and Use Workflow Timezone for choosing between the input’s zone and the workflow zone. Consult those controls in your installed node and make the choice explicit; the mirror is undated, truncated and establishes no version or edition.

Suggested exercise configuration, using the controls described by that community mirror: retain approvedISO = parsed.toISO() and sourceMillis = parsed.toMillis() after approval. Select Format a Date, set Date to the approvedISO field, choose Custom Format with yyyy-MM-dd, and set Output Field Name to displayDate. Turn Use Workflow Timezone off and Include Input Fields on; leave From Date Format unset for this ISO input. Treat displayDate only as a display field, separate from the payload timestamp. The following step creates and checks the UTC payload field.

In our view, a visible review record is a better exercise outcome than a plausible timestamp produced by guessing.

Sources: n8n-docs/docs/build/work-with-data/handle-special-data-types/work-with-dates-and-times.md at main · n8n-io/n8n-docs · GitHub, luxon/docs/parsing.md at master · moment/luxon · GitHub, luxon/docs/zones.md at master · moment/luxon · GitHub, n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.if.md at main · n8n-io/n8n-docs · GitHub, Date & Time | n8n Docs, n8n-docs/docs/build/work-with-data/transform-data/expression-reference/datetime.md at main · n8n-io/n8n-docs · GitHub

Check UTC output and instant equality

Finish the n8n date formatting path after the formatting node. Validate DateTime.fromISO($json.approvedISO), then create payloadTimestamp with DateTime.fromISO($json.approvedISO).toUTC().toISO(), using default conversion behavior. Keep displayDate separate: payloadTimestamp is the proposed payload’s timestamp. n8n’s expression reference documents that toUTC preserves the instant by default and toISO produces an ISO string.

Re-parse the actual payloadTimestamp field with DateTime.fromISO($json.payloadTimestamp) and require isValid before comparing its toMillis() value with the retained sourceMillis from the original approved parse. Only an equal comparison passes this suggested check. Compare instants rather than display text, and route an invalid payload timestamp or a mismatch to review.

Suggested worked example: for 2026-01-15T10:00:00+02:00, the expected payloadTimestamp is 2026-01-15T08:00:00.000Z. Re-parse that payload field with DateTime.fromISO and require its toMillis value to equal sourceMillis. The completion checklist is:

• Every record retains its original input and contract.
• Each fixture reaches its expected approved or review branch.
• Review records carry reasons and cannot reach the proposed payload.
• Approved records produce valid ISO output.
• Valid source and re-parsed output instants have equal toMillis values.

Sources: n8n-docs/docs/build/work-with-data/handle-special-data-types/work-with-dates-and-times.md at main · n8n-io/n8n-docs · GitHub, luxon/docs/parsing.md at master · moment/luxon · GitHub, n8n-docs/docs/build/work-with-data/transform-data/expression-reference/datetime.md at main · n8n-io/n8n-docs · GitHub

Reflect on the proposed solution

Your suggested solution should make interpretation inspectable: raw input, explicit parser, approval decision, formatted output and instant comparison. When a spring-forward fixture changes unexpectedly, compare its original wall-time components with the parsed components; a valid result can still reflect normalization. Use fromFormatExplain when investigating format-token matching.

Suggested reflection questions: Which assumptions came from the source contract? Which records needed human clarification? What destination field contract would you require before connecting the proposed payload to a write operation?

Sources: luxon/docs/zones.md at master · moment/luxon · GitHub, luxon/docs/parsing.md at master · moment/luxon · GitHub