Selfhosted - Executions still appear to be in UTC/Winter time for the UK

Describe the issue/error/question

Winter / Summer time change for the UK yesterday, I’m seeing the executions still in Winter /UTC Time and yet settings seems to be ok



What is the error message (if any)?

Please share the workflow

(Select the nodes and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow respectively)

Share the output returned by the last node

Information on your n8n setup

  • n8n version: 0.220.0
  • Database you’re using (default: SQLite): Postgres
  • Running n8n with the execution process [own(default), main]: main
  • Running n8n via [Docker, npm,, desktop app]: Docker

I think it could be the postgres DB


just to complete this question - I set the TZ and GENERIC_TIMEZONE in the N8N containers and the Postgres container to GMT. Then the execute times matched LOCAL TIME, including once executed in the past.

1 Like

Hey @0101binary0101,

I take it all is good now then and it was just a display issue rather than the executions actually running at the wrong times?

Hi @Jon , yeah but for me it caused some added confusion because n8n was using the summer time and the database remained in UTC which appeared to be causing a knock on effect to my ‘Wait for webhook’ test timings because as I was getting strange ‘wait for webhook timeout’ paths executed even though I had a selection made a response selection.

Now all seems good, thank you.

Ah yeah that will do it :slight_smile: On the plus side now you have sorted it you won’t hit this issue again.

True … but on the flip side, any schedules where specific hours are being used these are of course going to be flicking an hour out as they’ll be executing in GMT time, based upon the container TZ time.

Point in case is my checking of the N8N releases to pull the latest, now executes at 08:45 and 20:45, instead of 07:45 and 19:45 previously, the change from TZ=Europe/London in the TZ=GMT in the N8N container was made in the afternoon of the 27th.

For time critical stuff it just gets a bit quirky.

Hey @0101binary0101,

That is odd so my workflows are still running at their set time, I have Generic and TZ both set to Europe/London :thinking:

So originally I had TZ=Europe/London in my N8N container but my Postgres DB container was in UTC and I was seeing executions an hour out which is why I opened the post in the first place.

So setting both N8N and PostgresDB to TZ=GMT variable into the Postgres DB container has sorted the Display time to local time…

But the executions back an hour behind, e.g. they are using GMT time now.

showing that the n8n container is using TZ=GMT

I could try to do this again and shift both N8N container and Postgres to be Euope/London but this might have some other implications during the hour that is gained / lost during that switch overs tbh it’s a headache.

My test workflow:

That explains it, The main difference is that I set the TZ and Postgres time option for my Postgres container to Europe/London as well so it sorts itself out.

Ahhhh ok I need to find the ‘Postgres Time Option’ setting… as I’ve NOW set both N8N and Postgres TZ settings to TZ=Euope/London , Restarted both N8N and Postgres … but I’m seeing executing in 09:58, even though the schedule from the schedule node its saying 10:58… … I just need to find the Postgres Time Option.

Check the postgres config file in the container, I think I had to set it there as well.

Have been reading the : PostgreSQL: Documentation: 15: 8.5. Date/Time Types

And just tried setting PGTZ environment variable and again… still no difference in the N8N execution details.

Have even set the workflow to Pago-Pago timezone to see how bizarre this can get, execution still showing GMT, and the schedule node output showing the time for PagoPago

Ok Found it … as you say … it’s also in the postgressql.conf file !! meh !! lol

Thanks @Jon

[[email protected] pgdata]# grep timezone postgresql.conf
log_timezone = 'Etc/UTC'
timezone = 'Etc/UTC'#timezone_abbreviations = 'Default'     # Select the set of available time zone                                        # share/timezonesets/.
[[email protected] pgdata]#
1 Like

No problem at all :slight_smile:

Grrrrrrr… I wish I could say that did fix it … but STILL no joy , Executions still showing an hour behind … even though have set the TZ , PGTZ , changed postgresql.conf , all to say Europe/London.

Have tried things around alter system , alter db using Europe/London …restart the N8N and postgres containers BUT Still N8N is showing the execution in GMT time 11:50 , when it’s now 12:50

And what doesn’t make any sense if I change N8N back to GMT then the execute times would be displayed in LOCAL Time e.g. 12:50 , Is N8N storing anything in the database it creates at the FIRST initial time to indicate the Timezone it was created in ??

Have also added on a new Postgres query to look at Timezone selections …

select * from pg_settings where name = 'TimeZone';

Only can see this boot_val setting is GMT but I really have no idea where that is coming from

I thought it was nailed, I take it after setting the config the Postgres container was restarted? I didn’t bother with PGTZ on mine, There shouldn’t be anything for the timezone in the database which is why we use those env options or config files instead of having it available in the UI to be set… The workflow timezone would be saved in the workflow itself, For mine they are all the default still though.

Yeah it’s still not resolved … All the containers have been removed and re-started via the docker compose. I thought that the N8N as a Client to Postgres might do something fancy with the PGTZ.

The next step maybe to trash the postgres db and re-create it, and then re-import the workflows and creds again.

I’m intrigued to see the output of your from postgres.

select * from pg_settings where name = 'TimeZone';

So for that I get…

1 Like

Only difference I can see are the source and sourcefile settings, I’ll have to go and look to see what those mean.
I’m just looking at exporting my workflows and creds with a view to recreating but might not get around to re-creating the db till later or tomorrow.

1 Like