The `updatedAt` column in Data Tables uses wrong time zone

[DRSDavidSoft]

Bug Description

In n8n Data Tables, the row system timestamps appear inconsistent:

• When a row is first created, createdAt (and updatedAt) reflects my configured instance's timezone correctly.
• After updating the same row, updatedAt is stored and returned in UTC, causing createdAt and updatedAt to be shown in different timezones.

Note

If it matters, my .env has GENERIC_TIMEZONE set, but TZ is unset.

GENERIC_TIMEZONE=<MyTimeZone>

To Reproduce

1. Configure n8n with environment variables above
2. Create a Data Table.
3. Insert a new row using a flow.
4. Observe the row createdAt and initial updatedAt values (they match, and use correct time zone).
5. Update the same row (e.g. edit a cell) in a flow.
6. Observe that updatedAt is now in UTC, while createdAt remains in the original timezone/format.

Actual Behavior

createdAt appears in my local/instance timezone, but updatedAt appears in UTC after updates.

This row was created while my system shows the same date/time as "createdAt". When the row was edited, the "updatedAt" is expected to also reflect the current displayed date/time, however the value of the UTC date/time was used to update it instead.

Expected behavior

createdAt and updatedAt for Data Table rows should be consistent in storage and representation.
If timestamps are returned via API/UI, they should use a consistent standard (ideally ISO-8601 with offset), or consistently follow instance timezone rules.

Notes / Suspected Cause

There might be different code paths for initial insert vs update:

• DataTable “touch” logic uses JS new Date():
  • DataTableRepository.touchUpdatedAt() updates table entity updatedAt with new Date()
• Row updates go through DataTableRowsRepository.updateRows() and may set row updatedAt using database-side timestamps (e.g. CURRENT_TIMESTAMP), which can be UTC depending on DB/process configuration.

I'm not sure, I need to investigate the code more to be confident.

This suggests the row-level updatedAt might be set differently on INSERT vs UPDATE, or returned/serialized differently, producing the timezone mismatch.

Environment

• Hosting: self-hosted (bare-metal/VM), no Docker
• GENERIC_TIMEZONE=<MyTimeZone> is set
• TZ is NOT set
• Operating System: Ubuntu Linux 24.04 noble
• n8n Version: 2.6.4
• Node.js Version: v24.13.0
• Database: PostgreSQL
• Hosting: self hosted

[n8n-assistant]

Hey @DRSDavidSoft,

Thank you for reaching out! We’ve received your issue and are looking into it. To help us track this internally, we’ve created a Linear ticket with the reference: "GHC-6949".

We’ll keep you updated as we make progress, but if you have any additional details or context to share, feel free to add them here - it’s always helpful!

Thanks for your patience and for bringing this to our attention.

---

For INTERNAL use only: GHC-6949

[DRSDavidSoft]

This problem could also be the result of the way my current instance is set-up; I've recently migrated from SQLite to PostgreSQL.

I don't recall if this also used to be an issue in the previous database setup where it used SQLite -- if that is indeed the case, I'm not sure how to rectify this in my current PostgreSQL setup 😅