Skip to content

fix(core): Fix execution startedAt timezone issue with PostgreSQL#25054

Open
newbee1939 wants to merge 1 commit inton8n-io:masterfrom
newbee1939:fix/execution-startedAt-timezone
Open

fix(core): Fix execution startedAt timezone issue with PostgreSQL#25054
newbee1939 wants to merge 1 commit inton8n-io:masterfrom
newbee1939:fix/execution-startedAt-timezone

Conversation

@newbee1939
Copy link
Copy Markdown

@newbee1939 newbee1939 commented Jan 29, 2026

Summary

This PR fixes a bug introduced in v2.5.0 where execution timestamps (startedAt) were incorrectly stored in PostgreSQL when the database is configured for a non-UTC timezone (e.g., Asia/Tokyo).

Problem

Following the changes in #23146, the storage logic for startedAt was modified to use DateUtils.mixedDateToUtcDatetimeString. This helper explicitly converts Date objects to a UTC string before persistence.

In environments where PostgreSQL is set to a local timezone like JST (UTC+9), this causes a discrepancy:

  • Expected: 2026-01-30 22:50:00 JST stored as 2026-01-30 22:50:00+09.
  • Actual (v2.5.0): The UTC string 13:50:00 is stored as 2026-01-30 13:50:00+09, resulting in a 9-hour offset in the UI.

Solution

I have reverted the logic to pass the Date object directly to the query builder. This allows the database driver to handle the timezone conversion naturally based on the system/database configuration, restoring the original and correct behavior.

Before modification

Related Linear tickets, Github issues, and Community forum posts

#23146

Review / Merge checklist

  • PR title and summary are descriptive. (conventions)
  • Docs updated or follow-up ticket created.
  • Tests included.
  • PR Labeled with release/backport (if the PR is an urgent fix that needs to be backported)

@newbee1939
fix(core): Fix execution startedAt timezone issue with PostgreSQL
e75617b 
Pass Date object to setParameter() instead of converting to string
via DateUtils.mixedDateToUtcDatetimeString(). The string lacks timezone info, so PostgreSQL misinterprets it when not using UTC timezone.
@CLAassistant
Copy link
Copy Markdown

CLAassistant commented Jan 29, 2026 •
edited
Loading

CLA assistant check
All committers have signed the CLA.

@n8n-assistant n8n-assistant Bot added community Authored by a community member in linear DEPRECATED labels Jan 29, 2026
@n8n-assistant
Copy link
Copy Markdown
Contributor

n8n-assistant Bot commented Jan 29, 2026

Hey @newbee1939,

Thank you for your contribution. We appreciate the time and effort you’ve taken to submit this pull request.

Before we can proceed, please ensure the following:
• Tests are included for any new functionality, logic changes or bug fixes.
• The PR aligns with our contribution guidelines.

Regarding new nodes:
We no longer accept new nodes directly into the core codebase. Instead, we encourage contributors to follow our Community Node Submission Guide to publish nodes independently.

If your node integrates with an AI service that you own or represent, please email nodes@n8n.io and we will be happy to discuss the best approach.

About review timelines:
This PR has been added to our internal tracker as "GHC-6582". While we plan to review it, we are currently unable to provide an exact timeframe. Our goal is to begin reviews within a month, but this may change depending on team priorities. We will reach out when the review begins.

Thank you again for contributing to n8n.

cubic-dev-ai[bot]
cubic-dev-ai Bot reviewed Jan 29, 2026
View reviewed changes
Copy link
Copy Markdown
Contributor

@cubic-dev-ai cubic-dev-ai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No issues found across 2 files

@CodingArctic
Copy link
Copy Markdown

CodingArctic commented Feb 3, 2026

would be great to get this merged, I had this issue crop up in my self-hosted n8n instance using Postgres. here's my forum post if that helps get a review faster. i've had to rollback my version and hold off on latest updates.

@Dinhmanh96
Copy link
Copy Markdown

Dinhmanh96 commented Feb 4, 2026

image I also encountered the same error when running on Truenas; the accuracy deviation was always 8 hours.

@patbrennan
Copy link
Copy Markdown

patbrennan commented Feb 4, 2026

+1 experiencing this issue. Subscribed.

@hy2850
Copy link
Copy Markdown
Contributor

hy2850 commented Feb 5, 2026

Thank you for bringing this up. I'm also experiencing this in production.
Hope this gets merged soon.

@hy2850 hy2850 mentioned this pull request Feb 5, 2026
Closed
@krisn0x krisn0x mentioned this pull request Feb 10, 2026
Closed
@amwmedia
Copy link
Copy Markdown

amwmedia commented Feb 12, 2026

+1 I'm also running into this!

@jonasmuller98
Copy link
Copy Markdown

jonasmuller98 commented Feb 12, 2026

I'm also running into this...

@CodingArctic
Copy link
Copy Markdown

CodingArctic commented Feb 12, 2026 •
edited
Loading

after checking out issue #25465 i tried updating to the latest version and my issue has been resolved! specifically, i updated to v2.8.1, and now my execution times are accurate again.

@denni-hill
Copy link
Copy Markdown

denni-hill commented Feb 25, 2026

Wouldn't it be better to just set connection timezone to UTC?
It is not the only place where it breaks features. One more example is insights where if you select current date in filters instance screams with error that we select future (if your db's UTC offset is positive) date.

It is a pretty simple fix in db-connection-options.ts

In MySQL options n8n already had code that forced UTC connection timezone.
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@cubic-dev-ai cubic-dev-ai[bot] cubic-dev-ai[bot] left review comments

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

community Authored by a community member in linear DEPRECATED

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

9 participants

@newbee1939 @CLAassistant @CodingArctic @Dinhmanh96 @patbrennan @hy2850 @amwmedia @jonasmuller98 @denni-hill