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.
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.
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.
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.
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.
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.
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
[[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]#
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 ??
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';
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.
On the plus side now you have sorted it you won’t hit this issue again.
