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

Questions
1

Describe the problem/error/question

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.

I’ve posted more information about this problem here as well: The updatedAt column in Data Tables uses wrong time zone · Issue #26070 · n8n-io/n8n

Please share your workflow

N/A, because this happens in any “Update”/“Upsert” node action

Share the output returned by the last node

N/A

Information on your n8n setup

  • n8n version: 2.6.4
  • Database (default: SQLite): PostgreSQL
  • Running n8n via (Docker, npm, n8n cloud, desktop app): self hosted (bare-metal)
  • Operating system: Ubuntu Linux 24.04 noble
1 Like
2

Hi @DRSDavidSoft Please provide more information about n8n instance, for now if you are using docker instance you can always change the env variables to reset your time zone, in cloud you can do this via cloud dashboard,

3

Thank you @Anshul_Namdev for the suggestions!

I am running my own local instance on bare-metal using npm, no Docker is involved. I suspect this could be a bug in the way the data table node works with PostgreSQL (as I’ll describe),

Note: I accidentally posted the topic before having a chance to complete the information details, and since my account was new, the forum system didn’t give me a chance to either edit it or post a new one before my account was approved. Now that it has been approved, I have edited the original post above with what I was originally going to post.

For reference, here’s the complete information about this problem in my case:

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.

:information_source: 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.

Image
Image636×104 4.02 KB

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
4

Hi @DRSDavidSoft

adding the standard timezone variable is usually the easiest way around this while you wait for the github issue to get patched.

n8n uses GENERIC_TIMEZONE for the workflow executions and UI. but the node process and database drivers still rely on that TZ variable. when TZ is completely missing, the system just defaults to UTC during database updates.

just open your .env or systemd service file and add TZ=Your/Timezone. match it exactly to whatever you put for GENERIC_TIMEZONE.

restart your n8n service after you add it. usually aligns the timestamps perfectly from what i’ve seen on bare-metal setups.

1 Like
5

Yeah this is definitely a bug, not a config issue on your end. The createdAt vs updatedAt timezone mismatch you’re seeing in that screenshot (one showing your local time, the other UTC) lines up with what’s been reported before — looks like the create path respects GENERIC_TIMEZONE but the update path hits the database directly and gets UTC instead. Setting TZ in your environment might help as a bandaid but honestly the real fix needs to happen in the node code itself. I saw you already opened the GitHub issue and have a PR draft going which is great, hopefully the team picks it up during triage soon.

6

@A_A4 Thank you for the suggestion!

Sadly, it appears that having TZ set has no effect, the problem still persists:

Image
Image757×122 7.5 KB

(It may be that the TZ isn’t being picked up from the .env file, but since the other keys seem to have been picked up, this seems unlikely.)

In any case, I guess it would be best to wait until this is addressed in the node’s source code.

Thank you for the help! :+1:

7

@achamm Thank you for ensuring me that this isn’t a config problem on my end! :sweat_smile: Sadly, the band-aid TZ environment variable solution doesn’t seem to work for me, as I’ve posted above.

Hopefully the devs would pay attention to the GitHub bug – I’m completely baffled by how this might have been missed, but seeing that there was some activity in that area’s of the node’s source code a couple of months ago, it seems likely that such a bug could occur.

Regarding the PR, I’m not sure if it is indeed the right fix, since it was contributed by GitHub Coilot’s AI, but it appears that it is indeed worth investigating.

I hope the GitHub bug would get some attention sooner than later, until then I’ll have to wait.

Thank you for the help! :+1: