n8n 1.123.63 - Date Expression Fix

n8n [email protected] was published on July 2, 2026 with one core bug fix: Date values passed to the expression isolate are preserved. It is not marked as a prerelease, and the narrow scope makes this a targeted patch for workflow runs that depend on timestamp values inside expressions.

The full release notes and downloads are on the GitHub release page.

The release notes for n8n [email protected] name a single core fix: preserve Date values passed to the expression isolate. The changelog points to issue #33364 and commit 0e04591, so there is not a broad feature set to summarize here.

That small scope still matters for data workflows. Expression runtimes sit between input payloads, node parameters, and output data. If a JavaScript Date turns into a plain object, a string at the wrong point, or a value with different methods, downstream logic can take a different branch without looking like a transport failure.

The practical change is about type stability. Workflows that pass Date instances into expressions should now see those values remain dates inside the isolate. For timestamp logic, that is the difference between calling date methods directly and carrying workaround conversion code in every affected expression.

n8n is often used as glue around APIs, queues, webhooks, and scheduled jobs. Those flows tend to carry timestamps from multiple systems. A webhook event may include a creation time. A database read may emit an update time. A scheduled workflow may compare an execution time to an external cursor.

In that shape of workflow, Date preservation is not cosmetic. It affects filters, fan out conditions, API request bodies, and dedupe logic. A wrong type can change a query window, skip a record, or produce an output value that another system rejects.

This release is especially relevant when expressions handle mixed payloads from JavaScript code nodes and connector nodes. If an expression assumes Date methods are present, the isolate boundary has to keep that contract. The n8n 1.123.63 fix is about that boundary, not about adding a new connector or changing user interface behavior.

Because the release has one focused bug fix, rollout work should be equally focused. Treat it as a correctness patch for date heavy workflows, not as a platform feature release. The useful validation target is any workflow where an expression receives a Date object and then compares, formats, serializes, or branches on it.

Run a small set of representative workflows before widening the rollout:

  • Exercise workflows that pass JavaScript Date objects into expressions.
  • Compare outputs for schedules, webhook payloads, and API timestamps.
  • Watch for nodes that previously worked around the bug by converting dates to strings.
  • Check downstream systems that enforce timestamp formats in request bodies.

The last point matters because bug fixes can expose old workarounds. If a workflow manually converted dates because the isolate did not preserve them, the corrected behavior may make that workaround redundant or wrong. That is not a breaking change in the release notes, but it is still a reasonable regression check for production operators.

There are no migration steps, security advisories, connector additions, or documented breaking changes in the published notes. The release is a patch release around one core behavior. If a deployment is not affected by expression handling of Date values, the operational risk profile should be small, but the usual smoke tests still apply.

The limited scope also means there is no reason to infer broader scheduler or execution engine behavior from this release alone. The only stated change is the expression isolate fix. Keep the upgrade review tied to that fact and use the GitHub release page as the source record.