Node Wait scheduling execution for 3 hours after selected time

[hugoperes]

I’m having problem with timezone in n8n queue mode.

All servers are local time in my country’s timezone: America/Sao_Paulo

However, when using the Wait node for a scheduled execution, the execution ends up being scheduled for 3 hours after the scheduled time.

When querying the server time, I noticed that n8n is considering universal time (UTC) and not local time.

Would that be a bug? Is there a way around this?

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)

Share the output returned by the last node

Information on your n8n setup

• **n8n version:0.222.1
• **Database (default: SQLite):MySQL
• **n8n EXECUTIONS_PROCESS setting (default: own, main):own
• **Running n8n via (Docker, npm, n8n cloud, desktop app):npm
• **Operating system:Linux Ubuntu 22.04

[EmeraldHerald]

Hi @hugoperes - nice to see you back in the community!

Sorry about that initial reply that I’ve now scrapped, I just realised you’re not on cloud

Could you check your environment variables to see what your timezone is set to in n8n? You might not have set the GENERIC_TIMEZONE option.

You can find out more about how to configure your environment here.

If you’re using npm and not Docker, you can also run date in an execute command node to see what comes back.

Alternatively, if you open up the menu in the top-right of the workflow, you can also set the timezone for that specific workflow there:

Let me know if that helps!

[hugoperes]

So, both on the N8N side and on the server side, you have the right time zone as shown in the prints.

But I realize that the universal time is 3 hours longer.

I even wonder if n8n isn’t considering universal time instead of local time.

Note 1: This error only happens in n8n queue mode. In regular mode the timezone works correctly.

Note 2: The schedule trigger is also working perfectly with local time. This problem is only occurring when the execution enters Waiting mode through the WAIT node.

[hugoperes]

Worker instances do not have the GENERIC_TIMEZONE env

Could this be the reason for the problem?

[EmeraldHerald]

@hugoperes Yep, you just found your answer! You’ll need to set GENERIC_TIMEZONE to the timezone you want your n8n instance to be. Fix that up, and your next run of that workflow should fire off when you expect it to.

I’d suggest setting that env variable for your workers, and ensure that your database also has the correct timezone set. There’s been issues in the past when they don’t match.

For example, if you’re using Docker:

docker run -it --rm \
 --name n8n \
 -p 5678:5678 \
 -e GENERIC_TIMEZONE=YourTimezone\
 -v ~/.n8n:/home/node/.n8n \
 docker.n8n.io/n8nio/n8n \
 n8n start

and for npm, something like:

export GENERIC_TIMEZONE=YourTimezone && npx n8n start

[hugoperes]

I put the timezone in the workers.

I got the redis time zone and mysql is ok too.

But even so, n8n keeps scheduling the execution after 3 hours (universal time)

[EmeraldHerald]

Hi @hugoperes - sorry for the delay over the weekend!

Can you maybe try an expression instead in the wait node to ensure you’re manually setting the timezone? For you that would look something like this:

{{ DateTime.fromISO('2023-04-17T18:45', {zone: 'America/Sao_Paulo'}).toISO() }}

Can you let me know if that does the trick? Obviously you’d need to set that date to what time you actually want to run it at

By the way, n8n uses Luxon for date and time formatting and calculations, you can take a peek at some documentation here.

[hugoperes]

Thank you for your dedication in trying to help.

Even using the expression, the Wait node keeps adding + 3 hours to the scheduled time.

This issue is occurring in n8n queue mode. If you have an n8n to test with, that would be great.

In n8n regular mode, this problem does not occur.

[EmeraldHerald]

@hugoperes I was taking a look into this with @MutedJam - this looks like it might be a bug with how the date is displayed in the UI with the execution list, but the database etc. all have the correct timezone. We’re going to take a closer look at this tomorrow to test a little bit more, but it looks like we’re seeing the same as you at the moment.

[hugoperes]

Thank you very much! I’m stuck in the solution.

Note: In the node schendule, scheduling works at the right time. The problem is occurring only in the Wait node, whether it is scheduling in Time Interval or specific time.

[EmeraldHerald]

Just in the meantime until we have looked into the bug further (and the team can fix said possible bug), if you set the server timezone to UTC you wouldn’t encounter this problem. I know this isn’t ideal at all, we were just testing around trying to see how we could possibly unblock you at this point in time.

You could also set your local TZ environment variable on your computer to UTC, and that might work too. You can do this:

- GENERIC_TIMEZONE=America/Sao_Paulo
      - TZ=UTC

You can find a brief description on what that TZ variable does here. The advantage of this would be that you don’t need to change the OS time.

That was the only current workaround we could find in all of our testing. We’ll also resume testing tomorrow and alert the developers if we can’t find a solution

[hugoperes]

BINGO!

Solved the problem!

Anyway, I look forward to the correction in the Editor-UI.

[EmeraldHerald]

Hi @hugoperes - I just wanted to let you know that after further testing this is still reproducible, so we’ve added this to our bug tracker. I’ll let you know if and when I have an update on this!