Postgres output differ between bash and SQL exec. node

[utkuluk]

I am in Istanbul (UTC+3),
it’s 02:08, so the date is 28/08/2025.
But in UTC it’s still 27/08/2025 of course.

“SELECT NOW()::date;”

In postgres (bash) this returns 28/08,
in n8n postgres SQL execution node, it returns 27/08.

Every TZ settings I could find (in ubuntu, docker, n8n, postgres) is set to Europe/Istanbul, but this is the result.

Maybe it’s something simple,
I don’t know, just wanted to report this.

• **n8n version: Latest (**1.108.2, just updated)
• Database: postgres:15-alpine
• Running n8n via: Docker compose
• Operating system: Ubuntu 22.04 (remote server)

[jabbson]

Run this in execute statement postgres in n8n

you will most likely see UTC.

Now run this to get the NOW with the timezone shift:

or run this is you select NOW many times in the statment:

[utkuluk]

SHOW timezone;
SELECT current_setting(‘TimeZone’);
SELECT NOW(), CURRENT_DATE;
SELECT (NOW() AT TIME ZONE ‘Europe/Istanbul’)::date;

Result of this is (in n8n):

[
  {
    "TimeZone": "Europe/Istanbul"
  },
  {
    "current_setting": "Europe/Istanbul"
  },
  {
    "now": "2025-08-28T08:11:00.437Z",
    "current_date": "2025-08-27T21:00:00.000Z"
  },
  {
    "timezone": "2025-08-27T21:00:00.000Z"
  }
]

And the result in postgres bash:

n8n=# SHOW timezone;
    TimeZone     
-----------------
 Europe/Istanbul
(1 row)

n8n=# SELECT current_setting('TimeZone');
 current_setting 
-----------------
 Europe/Istanbul
(1 row)

n8n=# SELECT NOW(), CURRENT_DATE;
              now              | current_date 
-------------------------------+--------------
 2025-08-28 11:13:42.502521+03 | 2025-08-28
(1 row)

n8n=# SELECT (NOW() AT TIME ZONE 'Europe/Istanbul')::date;
  timezone  
------------
 2025-08-28
(1 row)

So in bash, it’s what it supposed to be.
But in n8n node, it’s different.

Now the other part (in n8n):

SET TIME ZONE 'Europe/Istanbul';
SELECT NOW()::date;
SELECT NOW()::date;
SELECT NOW()::date;

The result of this (in n8n):

[
  {
    "now": "2025-08-27T21:00:00.000Z"
  },
  {
    "now": "2025-08-27T21:00:00.000Z"
  },
  {
    "now": "2025-08-27T21:00:00.000Z"
  }
]

And the result in postgres bash:

n8n=# SET TIME ZONE 'Europe/Istanbul';
SET
n8n=# SELECT NOW()::date;
    now     
------------
 2025-08-28
(1 row)

n8n=# SELECT NOW()::date;
    now     
------------
 2025-08-28
(1 row)

n8n=# SELECT NOW()::date;
    now     
------------
 2025-08-28
(1 row)

But later I thought:
Maybe it’s because I have created the database (a month ago) before I set the timezone settings in docker, postgres, n8n, ubuntu etc. (1-2 days ago).

[jabbson]

I see, thank you for running these tests.

So,… I think the “difference” could be not about Postgres time zone; but rahter about client-side JSON rendering of date-like values.

Let’s try to avoid it.

When you want a calendar date (not a timestamp), return TEXT, not a date/timestamp type. E.g.:

• Always-robust, ignores session tz, returns a plain string:

result will be

[
  {
    "local_date":  "2025-08-28"
  }
]

• Or, if you trust the session tz already set to Europe/Istanbul:

• If you need midnight as a local timestamp string (not shifted to Z):

Now,… if you must keep timestamps:

Return them as strings in the target timezone to avoid automatic UTC normalization:

Quick sanity checks you can run in n8n:

which for me returns (should be slightly different for you):

[
  {
    "tz": "UTC",
    "now_timestamptz": "2025-08-28T14:30:21.925Z",
    "now_local_ts": "2025-08-28T17:30:21.925Z",
    "local_date_text": "2025-08-28"
  }
]

You’ll see now_timestamptz end with Z (UTC JSON), while local_date_text is the human date you expect (2025-08-28) with no timezone juggling.

The bottom line: your DB is fine I think and on Europe/Istanbul. n8n is displaying date-like values in UTC. Return formatted text for dates (or any time you care about a specific local representation) to make the result unambiguous.

Sorry about screenshots, the forum would let me paste SQL… ugh.

[utkuluk]

Thanks for support.

TO_CHAT() actually solves it, I know, an LLM told me about it and I trired. But I thought maybe something is wrong with the n8n’s handling, so I just wanted to write about it here more like a feedback.

[jabbson]

Hope this was helpful (if if was, kindly mark one of the answers as solution and thank you). Optionally, you may want to also open a bug about about client-side JSON rendering of date-like values in n8n and provide an example of how it does work and how you expect it to (bugs can be opened here).

Cheers!