The datetime should remain consistent across: 1. Manual entry in the Data Table UI 2. Page refresh 3. Reading the row using the **Get Row(s)** node The original value: ```text 2026-05-19T15:15:00.000-03:00 ``` Should represent the same instant when returned by the node, for example: ```text 2026-05-19T18:15:00.000Z ``` Or it should preserve the original timezone representation, depending on the intended Data Table behavior. But it should **not** become: ```text 2026-05-19T21:15:00.000Z ``` Because that represents a different instant.

n8n - ✅(Solved) Fix Data Table date column shifts timezone value by +3 hours after refresh and when read by Get Row(s) [1 pull requests, 4 comments, 4 participants]

gabrielhmsantos · 2026-05-19T16:13:29Z

[n8n] PR 30765: fix core : Use TIMESTAMPTZ for Data Table date columns in Postgres - Repository: n8n-io/n8n - Author: abdullah5361k - State: open | merged: Fal… # PR #30765: fix(core): Use TIMESTAMPTZ for Data Table date columns in Postgres - Repository: n8n-io/n8n - Author: abdullah5361k - State: open | merged: False - Link: https://github.com/n8n-io/n8n/pull/30765 ## Description (problem / solution / changelog) When adding a date column to an existing Data Table in Postgres, the column was created as `TIMESTAMP` (without timezone) instead of `TIMESTAMPTZ`. This caused a timezone-offset shift bug on every page refresh: - User enters `2026-05-19T15:15:00.000-03:00` - After refresh it becomes `2026-05-19T18:15:00.000-03:00` (+3h shifted) - The Get Row(s) node returns `2026-05-19T21:15:00.000Z` instead of `2026-05-19T18:15:00.000Z` **Root cause:** The `pg` driver returns `TIMESTAMP` columns as raw strings (e.g. `"2026-05-19 18:15:00.000000"`) without timezone info. The browser treats these as local time instead of UTC, causing the repeated offset shift. `TIMESTAMPTZ` columns are returned as proper JS `Date` objects, which serialize correctly. **Fix:** - Changed `dataTableColumnTypeToSql()` to use `TIMESTAMPTZ` for Postgres date columns, making `addColumn` consistent with `createTableWithColumns` (which already used `TIMESTAMPTZ`) - Hardened `normalizeDate()` to handle space-separated Postgres TIMESTAMP strings with microsecond precision as a fallback for legacy columns **Note:** A database migration to convert existing `TIMESTAMP` date columns to `TIMESTAMPTZ` is still needed for deployments created before this fix. Happy to add it if the team can point me to the right migration pattern for dynamic user tables. ## Related Linear tickets, Github issues, and Community forum posts fixes #30752 ## Review / Merge checklist - [x] I have seen this code, I have run this code, and I take responsibility for this code. - [x] PR title and summary are descriptive. - [ ] Docs updated or follow-up ticket created. - [x] Tests included. - [ ] PR Labeled with `Backport to Beta`, `Backport to Stable`, or `Backport to v1` ## Changed files - `packages/cli/src/modules/data-table/__tests__/sql-utils.test.ts` (modified, +30/-0) - `packages/cli/src/modules/data-table/utils/sql-utils.ts` (modified, +10/-3) ## Fixed - Fixed by PR: fix(core): Use TIMESTAMPTZ for Data Table date columns in Postgres (https://github.com/n8n-io/n8n/pull/30765) ### Bug Description I found a possible timezone handling bug in the **Data Tables** feature when using a column of type `date`. When I manually enter a datetime value in a Data Table using the UTC-3 timezone, the value initially appears to be stored correctly. However, after refreshing the page, the value is shifted by **+3 hours** while still keeping the `-03:00` timezone offset. Additionally, when reading the same row using the **Get Row(s)** node, the returned value is also shifted and comes back as UTC time. ### To Reproduce 1. Create or open a Data Table. 2. Add a column with type `date`. 3. Insert a datetime value using UTC-3 timezone. Example: ```text 2026-05-19 15:15:00 ``` 4. Save the row. The value is initially displayed/stored as: ```text 2026-05-19T15:15:00.000-03:00 ``` 5. Refresh the browser page using `F5`. 6. Check the same Data Table row again. 7. Add a **Get Row(s)** node and read the row from the Data Table. ## Current behavior After refreshing the page, the Data Table value is changed from: ```text 2026-05-19T15:15:00.000-03:00 ``` To: ```text 2026-05-19T18:15:00.000-03:00 ``` When using the **Get Row(s)** node, the returned value is: ```text 2026-05-19T21:15:00.000Z ``` This means the value keeps being shifted forward instead of preserving the original datetime. ### Expected behavior The datetime should remain consistent across: 1. Manual entry in the Data Table UI 2. Page refresh 3. Reading the row using the **Get Row(s)** node The original value: ```text 2026-05-19T15:15:00.000-03:00 ``` Should represent the same instant when returned by the node, for example: ```text 2026-05-19T18:15:00.000Z ``` Or it should preserve the original timezone representation, depending on the intended Data Table behavior. But it should **not** become: ```text 2026-05-19T21:15:00.000Z ``` Because that represents a different instant. ### Debug Info # Debug info ## core - n8nVersion: 2.21.4 - platform: docker (self-hosted) - nodeJsVersion: 24.15.0 - nodeEnv: production - database: postgres - executionMode: scaling (single-main) - concurrency: -1 - license: enterprise (production) - consumerId: 0ead5edc-a047-4f3e-a

n8n2026-05-19 16:13:29

ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

n8n-io/n8n#30752•Fetched 2026-05-20 03:59:06

View on GitHub

Comments

Participants

Timeline

Reactions

Author

Participants

Timeline (top)

commented ×4mentioned ×4subscribed ×4cross-referenced ×1

Error Message

error: all

Root Cause

Because that represents a different instant.

Fix Action

Fixed

Fixed by PR: fix(core): Use TIMESTAMPTZ for Data Table date columns in Postgres (https://github.com/n8n-io/n8n/pull/30765)

PR fix notes

PR #30765: fix(core): Use TIMESTAMPTZ for Data Table date columns in Postgres

Repository: n8n-io/n8n
Author: abdullah5361k
State: open | merged: False
Link: https://github.com/n8n-io/n8n/pull/30765

Description (problem / solution / changelog)

When adding a date column to an existing Data Table in Postgres, the column was
created as TIMESTAMP (without timezone) instead of TIMESTAMPTZ. This caused a timezone-offset shift bug on every page refresh:

User enters 2026-05-19T15:15:00.000-03:00
After refresh it becomes 2026-05-19T18:15:00.000-03:00 (+3h shifted)
The Get Row(s) node returns 2026-05-19T21:15:00.000Z instead of 2026-05-19T18:15:00.000Z

Root cause: The pg driver returns TIMESTAMP columns as raw strings (e.g.
"2026-05-19 18:15:00.000000") without timezone info. The browser treats these
as local time instead of UTC, causing the repeated offset shift. TIMESTAMPTZ
columns are returned as proper JS Date objects, which serialize correctly.

Fix:

Changed dataTableColumnTypeToSql() to use TIMESTAMPTZ for Postgres date columns,
making addColumn consistent with createTableWithColumns (which already used TIMESTAMPTZ)
Hardened normalizeDate() to handle space-separated Postgres TIMESTAMP strings
with microsecond precision as a fallback for legacy columns

Note: A database migration to convert existing TIMESTAMP date columns to
TIMESTAMPTZ is still needed for deployments created before this fix. Happy to
add it if the team can point me to the right migration pattern for dynamic user tables.

Related Linear tickets, Github issues, and Community forum posts

fixes #30752

Review / Merge checklist

I have seen this code, I have run this code, and I take responsibility for this code.
- PR title and summary are descriptive.
- Docs updated or follow-up ticket created.
- Tests included.
- PR Labeled with Backport to Beta, Backport to Stable, or Backport to v1

Changed files

packages/cli/src/modules/data-table/__tests__/sql-utils.test.ts (modified, +30/-0)
packages/cli/src/modules/data-table/utils/sql-utils.ts (modified, +10/-3)

Code Example

2026-05-19 15:15:00

---

2026-05-19T15:15:00.000-03:00

---

2026-05-19T15:15:00.000-03:00

---

2026-05-19T18:15:00.000-03:00

---

2026-05-19T21:15:00.000Z

---

2026-05-19T15:15:00.000-03:00

---

2026-05-19T18:15:00.000Z

---

2026-05-19T21:15:00.000Z

RAW_BUFFERClick to expand / collapse

Bug Description

I found a possible timezone handling bug in the Data Tables feature when using a column of type date.

When I manually enter a datetime value in a Data Table using the UTC-3 timezone, the value initially appears to be stored correctly. However, after refreshing the page, the value is shifted by +3 hours while still keeping the -03:00 timezone offset.

Additionally, when reading the same row using the Get Row(s) node, the returned value is also shifted and comes back as UTC time.

To Reproduce

Create or open a Data Table.
Add a column with type date.
Insert a datetime value using UTC-3 timezone.

Example:

2026-05-19 15:15:00

Save the row.

The value is initially displayed/stored as:

2026-05-19T15:15:00.000-03:00

Refresh the browser page using F5.
Check the same Data Table row again.
Add a Get Row(s) node and read the row from the Data Table.

Current behavior

After refreshing the page, the Data Table value is changed from:

2026-05-19T15:15:00.000-03:00

To:

2026-05-19T18:15:00.000-03:00

When using the Get Row(s) node, the returned value is:

2026-05-19T21:15:00.000Z

This means the value keeps being shifted forward instead of preserving the original datetime.

Expected behavior

The datetime should remain consistent across:

Manual entry in the Data Table UI
Page refresh
Reading the row using the Get Row(s) node

The original value:

2026-05-19T15:15:00.000-03:00

Should represent the same instant when returned by the node, for example:

2026-05-19T18:15:00.000Z

Or it should preserve the original timezone representation, depending on the intended Data Table behavior.

But it should not become:

2026-05-19T21:15:00.000Z

Because that represents a different instant.

Debug Info

Debug info

core

n8nVersion: 2.21.4
platform: docker (self-hosted)
nodeJsVersion: 24.15.0
nodeEnv: production
database: postgres
executionMode: scaling (single-main)
concurrency: -1
license: enterprise (production)
consumerId: 0ead5edc-a047-4f3e-aac3-91301703d8e2

storage

success: all
error: all
progress: false
manual: true
binaryMode: database

pruning

enabled: true
maxAge: 336 hours
maxCount: 10000 executions

client

userAgent: mozilla/5.0 (windows nt 10.0; win64; x64) applewebkit/537.36 (khtml, like gecko) chrome/148.0.0.0 safari/537.36
isTouchDevice: false

cluster

instanceCount: 3
versions: 2.21.4
instances:
- instanceKey: 5ae06943-78b4-4520-b0f2-1d59f770557c, hostId: worker-e76f06265dae, instanceType: worker, instanceRole: unset, version: 2.21.4
- instanceKey: 667c76cd-fde2-4a6d-ad2d-dc288f91b4cb, hostId: webhook-2099c4ef32dc, instanceType: webhook, instanceRole: unset, version: 2.21.4
- instanceKey: 445c7287-0204-4bc1-996a-a3789925c250, hostId: main-fd1de03f5268, instanceType: main, instanceRole: leader, version: 2.21.4
checks:
- check: hostid-clash, status: succeeded, warnings: -
- check: lifecycle, status: succeeded, warnings: -
- check: split-brain, status: succeeded, warnings: -
- check: version-mismatch, status: succeeded, warnings: -

Generated at: 2026-05-19T16:12:16.754Z

Operating System

Docker

n8n Version

2.21.4

Node.js Version

24.15

Database

PostgreSQL

Execution mode

queue

Hosting

self hosted

Vote matrix · Quick signals

Works

Did the solution work? Tap to confirm.

Easy Fix

Was it a quick fix?

Time Saver

Did it save you time?

Blocking

Was it severely blocking?

Common Issue

Are others likely hitting this too?

Flaky / Intermittent

Is it intermittent?

Verified / Reproducible

Can you reproduce it reliably?

FAQ

Expected behavior

The datetime should remain consistent across:

Manual entry in the Data Table UI
Page refresh
Reading the row using the Get Row(s) node

The original value:

2026-05-19T15:15:00.000-03:00

Should represent the same instant when returned by the node, for example:

2026-05-19T18:15:00.000Z

Or it should preserve the original timezone representation, depending on the intended Data Table behavior.

But it should not become:

2026-05-19T21:15:00.000Z

Because that represents a different instant.

#memory management #API rate limit #retriever error #indexing error #inference speed

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

n8n - ✅(Solved) Fix Data Table date column shifts timezone value by +3 hours after refresh and when read by Get Row(s) [1 pull requests, 4 comments, 4 participants]

Recommended Tools

GitHub issue graph ai analysis

Error Message

Root Cause

Fix Action

Fixed

PR fix notes

PR #30765: fix(core): Use TIMESTAMPTZ for Data Table date columns in Postgres

Description (problem / solution / changelog)

Related Linear tickets, Github issues, and Community forum posts

Review / Merge checklist

Changed files

Code Example

Bug Description

To Reproduce

Current behavior

Expected behavior

Debug Info

Debug info

core

storage

pruning

client

cluster

Operating System

n8n Version

Node.js Version

Database

Execution mode

Hosting

FAQ

Expected behavior

Still need to ship something?

RELATED_DISCOVERY

TRENDING