Decaf Blog Data pipelines, open-source tooling, reverse engineering, and systems notes

n8n [email protected] - Date Expression Fix

3 min read

n8n [email protected] was published on July 2, 2026, with one core bug fix: Date values passed to the expression isolate are now preserved. For data engineers using n8n as workflow glue around ETL, ELT, and web processing jobs, the useful part is narrower than a feature release: time values should remain actual Date objects when expression code receives them. This release is not marked as a prerelease.

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

Date values stay intact

The named bug fix is core: Preserve Date values passed to the expression isolate, tracked as #33364 and shipped in commit 0e04591. That wording is specific. The release notes do not claim changes to scheduling, connectors, queue execution, or storage. They say that a Date value entering the expression isolate should remain a Date value.

That matters because n8n expressions often sit between HTTP intake, trigger metadata, and downstream writes. If a Date is coerced into a string or plain object at the boundary, expression logic can lose methods such as getTime() or create silent differences in comparison code. The release note is small, but the affected surface is the place where pipeline state often turns into routing, filtering, or payload shaping.

Expression isolation is a pipeline boundary

The expression isolate is a trust and execution boundary. It is where user supplied expression code evaluates data without giving that code the same access as the host process. Any serialization or cloning step at that boundary has to keep common runtime types straight. In this release, the type called out is Date.

For ETL and ELT workflows, dates are not cosmetic fields. They drive incremental windows, dedupe keys, retry gates, retention checks, and API cursor math. A workflow that pulls records modified after a stored timestamp is only as correct as the timestamp object it evaluates. If a workflow compares dates after an expression boundary has changed their type, the result can be a bad extract window rather than an obvious crash.

Operator impact is narrow

This is a patch release with one listed bug fix, so there is no sign in the notes of a schema migration, config change, CLI change, or connector behavior change. Operators should read that as a focused correctness update, not a broad platform update. The absence of extra bullets is useful information.

For self hosted n8n estates, the practical validation is simple: run workflows that pass Date values into expressions and check branches, filters, and payload mapping around those values. Pay attention to jobs that use trigger times, webhook timestamps, API record timestamps, or calculated ranges. Those are the places where this fix should show up first if the older behavior affected a workflow.

Because the GitHub release page only lists this one fix, there is no reason to infer a wider application change. The commit is worth reading if your workflows depend on exact JavaScript object identity or Date methods inside expressions. Otherwise, this release is mostly a small risk reduction around temporal data in workflow logic.

Where to get it