Describe the issue/error/question
the odd behavior occurs in the “Workflow Executions” overview. Whenever a workflow is running, the time is being displayed correctly. However once the workflow has been completed, the recorded time is -1 hour. I was made aware of the odd behavior after the transition to winter time a couple of days ago xD
I checked the following times/timezones. All of them are correct:
- n8n server host
- n8n and postgres docker container
- n8n (defined in docker-compose.yml with GENERIC_TIMEZONE=Europe/Berlin )
- Windows VM I’m using to access the n8n web interface over chrome
The n8n instance is running in a corporate environment. I could not reproduce this behavior on any other n8n instance.
I suspect the “Workflow Executions” overview displays the time based on the user location/timezone and not the timezone defined with the GENERIC_TIMEZONE variable.
I hope someone knows where the “Workflow Executions” overview gets its time from? Any other ideas are also welcome! : )
Working with n8n is enjoyable, I’ts really neat ^^
Thank you very much!
Information on your n8n setup
- n8n version: 0.202.1
- Database you’re using (default: SQLite): postgres 14 (docker container)
- Running n8n via [Docker, npm, n8n.cloud, desktop app]: docker compose
Welcome to the community
Do you also have the TZ option set in the env options? I am wondering if maybe the Schedule is showing the correct times at first with GENERIC_TIMEZONE but the container for some reason has not updated the time yet.
Hi @Jon ,
Thanks for your answer! : )
Are you referring to the docker env options?
I set the timezone inside docker by just mapping the timezone and localtime files into to containers like this:
I’m going to try to use a docker specific variable instead : )
By the way the time in chrome is correct. I confirmed it using the developer tools like this:
It is more the TZ env option specifically, I have have issues with my own instances in the past when I have not set it.
in my docker-compose file I commented out my old solution to map the timezone into the containers:
… and used the TZ variable instead
After applying the change (docker-compose up -d) I did not see change. The time in the “Workflow Executions” overview still lags 1 hour behind. I’ll continue to play around with different timezone settings… : )
Hi, just want to know whether there is any solution yet regarding this one? I have exactly the same problem.
I have similar problem. n8n version 0.217.1, Running on docker/kubernetes setup, docker timezone is set by
ENV TZ Europe/Helsinki, so UTC+02. The workflow settings timezone is also correct. Executions are showing times 2 hours earlier than they are actually ran. Testing out new Date() and offset in code node, I get the wrong time in the output:
and from the console.log I get the actual, correct time (11:31):
[Node: "Code"] Mon Mar 20 2023 11:31:36 GMT+0200 (Eastern European Standard Time)
[Node: "Code"] -120
Inside my custom nodes, that also use new Date() and other related functions, I am getting correct times.
So it seems that when that Date object is put into the return json, it’s going there by date.toISOString() function, which doesn’t take into account timezones. And in case like shown in the image, it would be up to the developer to make correct conversion. But since the error is also happening in the Executions view, I guess something similar is going on there.
EDIT: Just came to my mind that I am not sure if the database timezone is set correctly, that could explain the wrong execution time shown. I’ll investigate and return when I have more information on this.
Just to add another having this issue. I’m running version 0.224.4 in docker with TZ set to Europe/London in the env options. The flows run at expected time when set to run with the Schedule Trigger (using cron) but the executions log is always -1 hour. I also have the Timezone set to Europe/London in the Workflow settings. Could it be a DST issue ?
My instance also runs as Europe/London and I don’t have this issue at the moment.
What database are you using?
@Jon That’s strange alright. I use mysql and I just ran a SELECT NOW() command to check and it’s giving me the correct time !
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.