@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.
@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.
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:
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