Timezone ignored in webform submittedAt time

Questions
1

Describe the problem/error/question

The time in the submittedAt value of a webform output is always in UTC. I have the env var set to my timezone, and also set the workflow timezone manually to test. My Timezone in this case is +10.

What is the error message (if any)?

None

Please share your workflow

Share the output returned by the last node

[
{
"Meeting Name": "Test Meeting",
"Hour": 8,
"Minute": 30,
"AM-PM": "AM",
"submittedAt": "2024-05-24T21:48:45.272Z",
"formMode": "test"
}
]

Information on your n8n setup

  • n8n version: 1.42.1
  • Database (default: SQLite): Postgres
  • n8n EXECUTIONS_PROCESS setting (default: own, main): default
  • Running n8n via (Docker, npm, n8n cloud, desktop app): docker
  • Operating system: Ubuntu Server 22.04
2

Hi @revilo951

May I ask how you have set the env variable?

Also, did you configure any timezone setting for your docker container?

3

Hi @ria

I set the env variable in my docker-compose:

    environment:
      - GENERIC_TIMEZONE="Australia/Sydney"

I also set the timezone in the settings for the individual workflow, no change.

In a shell in the container, the time is correct for my timezone.

4

Try without the quotes :upside_down_face:

image
image656×112 7.95 KB

5

Well that’s a little embarrassing - I actually have it without the quotes. I didn’t have access to my compose file, so googled the syntax for docker-compose env vars.

image
image775×160 11.3 KB

We’re still at square one, I’m afraid.

6

What happens if you completely remove your docker timezone settings?

Do you get the same result when testing and in production environment?

7

Same with production and testing.

Same with or without the env vars.

I’m still getting submittedAt returned in Zulu, when I need my own time zone.

image
image452×207 4.82 KB

Is this one a bug? Happy to submit a bug report, if that helps.

8

Hi @revilo951

I just want to make sure, you have the docker variable TZ=Australia/Sydney set right in the n8n env variables as well, yeah?

And did you stop and start the container again rather than doing a restart? (Also cleared your browser cache?)

9

Hi @ria

Yep, TZ=Australia/Sydney is set too.

I’ve tested the changes with both docker-compose up -d and docker-compose up -d --force-recreate. The issues persist across multiple browsers, so it’s not browser cache either.

10

Hi @ria

Did you get any further with this one?

I’m not sure what your local timezone is, but in the example where you tested it, it looks to me like the submittedAt for you was also returned in Zulu (UTC), and not the specified timezone?

On another note - it looks like there’s an error with the timezones for Australia

image
image916×177 9.99 KB

Hobart, Melbourne, and Sydney should all be +10, only during daylight saving are they +11.

11

Hi @revilo951
So sorry for the delayed response! :bowing_woman:

You are right, the timezone settings appear to have no effect on the submittedAt value from the form node output.

We are currently investigating this internally.

Will keep you posted! :pray:

12

Hi @ria

Any progress with this one?

13

Hi @revilo951

We have this on our agenda for Q3 and will post here when this has been fixed :pray:

14

It’s quite simple to change the timezone returned by the form trigger using an expression, e.g. {{ $json.submittedAt.toDateTime().setZone('AET') }}

Would that work for you?

15

This is what I’m having to do currently.

16

Also, any word on the Australian time zones being incorrect?

Or am I best to start another forum post?

17

Hi @revilo951

We’re working on it :slight_smile: Will post here once it’s been released!

For reference, the internal tickets are:

  • 1739/inaccurate-timezones

  • 1415/n8n-form-trigger-node-timezone-ignored-in-submittedat

18

We already have a PR to fix this. We can hopefully get this fix out in tomorrow’s release.

19

I looked in the code for this, and we do intentionally return an ISO-8601 timestamp. and not just here, but consistently across all the nodes (that I checked).

From a UX perspective it is understandable to expect a local timestamp for the form’s submittedAt, but we probably shouldn’t change just one node introducing inconsistencies between different node types, since that’s not great for UX either.

We’ll discuss this internally and update here once we have something to share.

20

That makes sense, I guess this one won’t be a straight-forward decision then. Good luck! :slight_smile: