What is the API timezone?

All times are stored in UTC. See below. The value property returns the time in UTC, however the text property returns the time as it is visible on the board.

Hi @basdebruin ,
I am somewhat confused.
This is how the value is displayed on my board:

This is how the API returns it:

Text > 2023-10-28 15:00 is not how it is displayed on my board, is it?

Value > 2023-10-28 13:00 is the time in UTC? My profile timezone is GMT+01. How was 09:00 in the UI converted to 13:00?

I tested changing the timezone in my profile, but it did not change the value in the UI, or the value in the “value” field, but it does change the value returned in “text” and “time”.

What is the TZ of the user that is part of the token you use?

The time zone in the profile? It is GMT +01 Vienna. I am using the token in Developer > My access tokens.

Looks like the token refers to a user that has (or had??) it’s TZ set to CET+6

Very strange, like I mentioned:
I tested changing the timezone in my profile, but it did not change the value in the UI, or the value in the “value” field, but it does change the value returned in “text” and “time”. No idea why it is only partially? storing previous time zone information, or maybe I need to reset the instance somehow to update the UI.

Changing your TZ in monday should change your board, did you refresh your board?

I did, even restarted my browser. Changing timezone does not seem to affect the date/hour set in Date type columns in the UI, but it does change the values returned from querying the API. Does it update Date type columns for you?

I just tested this and changing the TZ in monday does NOT change the column value on your board (I can’t remember if this was the case a while ago). The value property (in CET) remains unchanged (as it should) and the text property shows the time in the changed TZ. So, now the text property does not give you what the user sees. I think this is a monday bug introduced not too long ago.

I see, thank you for testing and confirming.
Just to confirm:
The value property (in CET)
By CET you mean Central European Time? The value is not in UTC?

oops… I meant UTC

To me the bug is that the board contents is not updated after changing the TZ, not even after a refresh or login / logout. The API response seems to be ok to me.

Thank you @basdebruin !!!

Hello,
I thought of another related question, and I hope you could help.
When a hour is not specified for a Date type column, the API only returns a date.

value={“date”:“2023-11-16”,“changed_at”:“2023-11-06T10:47:47.932Z”}

Should this be considered as being in UTC? Like 2023-11-16T00:00:00Z? Not sure if people can have the displayed date in the user-interface change based on their timezone when an hour is not specified (Changing timezone doesn’t seem to change anything, but this was an UI bug, so just wanted to confirm if possible.)

In general (what it used to be 🙂) the value return always in UTC (also for dates without time - @midnight UTC). The text was always returning in timezone from user’s profile. Let’s see if monday will fix the UI (I am in contact with them and they can reproduce)

Alright, so I actually had quite a bit of back-&-forth on this issue recently, so happy to shed some additional light on all of this!

The time within the Data column is directly related to your device settings & NOT your Monday profile. You can test this by manually setting your PC time zone to be different & you’ll see all the board times change on refresh.

Automations; however, ARE based off of your Monday profile. They’re also based off the user who set up the automation. We ran into a problem where I set up some automations (I’m GMT -5) & our users on GMT+0 were getting notifications showing my local time & not theirs.

Lastly, it’s worth noting that the time zone options within Monday are labeled in such a way that you should always base it on location, not current GMT-related time zone. E.g. The time zone for (GMT -05:00) Eastern Time (US & Canada) always shows GMT -5, even when locally we’re on Daylight Savings Time & actually at GMT -4.

Thanks, Meghna for starting the thread. I understand that automations are based on the profile of the user who sets them up. My question is:

If Person A (UK time zone) creates an automation made by an integration app, and Person B (US time zone) triggers it:

1. The app server receives Person B’s user ID and profile information.
2. The integration needs Person A’s time zone to maintain consistency.

How do we determine Person A’s time zone in this scenario? It’s crucial for representing time columns consistently across the board, regardless of who triggers the integration.

Otherwise, the same time column could be translated into multiple timezones depending on whoever triggers the automation, leading to confusion.

cc @Matias.Monday @basdebruin

Always mutate the time using UTC for one.

Second, when you read the text of a date column its in the local time based on user settings. But, the value is in UTC. If you use the … on DateValue { date, time } then this is also in UTC.

You can query users by ID and get the utc_hours_diff or time_zone_identifier to calculate their correct time zone though. This may be useful if sending emails or notifications and you want to use the recipients time zone (from the UTC value)

So basically, its going to be in UTC on the backend. Its just the display text thats in a local time - that exists for UI apps to get the value in the time zone of the user session (since the seamless authentication will be the active user).

Hi, Cody. Thank you for taking the time and the detailed reply.

I agree with all the points you mentioned.

So I’m trying to query user A by ID (to get their timezone information) as you said, but in my example, I have person B’s user ID.

"
If Person A (UK time zone) creates an automation made by an integration app, and Person B (US time zone) triggers it:

The app server receives Person B’s user ID and profile information.
The integration needs Person A’s time zone to maintain consistency."

What I want is person A’s time zone, and what I have is person B’s user ID. Do you have any recommendation to get this done? Or is my example not making sense somehow, which could totally be the issue actually.

Integrations apps, a user field with the “context” as the source rather than “trigger output” will contain the user ID of the person who created the automation - not the person who triggered it.

Secondly, the JWT payload itself contains the same user ID (the short lived token user).

Lastly, if you use the short lived token with a {me{time_zone_identifier, utc_hours_offset}} you get the values of the user whose short lived token it is - which in integrations is ALWAYS the user who created the recipe.

But my question is WHY do you need to know the time zone? What are you doing where you’re getting a local time from monday.com and need to know the users time zone? Date columns return UTC - and you write in UTC. You shouldn’t need to convert anything.

Unless you are writing dates to text with an integration and want it in the time zone of the recipe creator - in which case, get the date using the short lived token, the date columns “text” field will be in the same time zone consistently (unless the user changes it) - that of the user who created the recipe because thats whose token you are using when you use a short lived token.

“in integrations is ALWAYS the user who created the recipe.”

Thank you. I missed this part.

“Unless you are writing dates to text with an integration and want it in the time zone of the recipe creator” aha, you got me. Exactly this. If I were to use the timezone of the ones triggering the automation, I’m afraid the dates will follow a variety of timezones for a distributed team - that’s not good.

I’m writing out datetime data for users to read and UTC isn’t user friendly.

Thanks a bunch of the knowledge drop Cody!

Yes, that whole thing with automations running as the recipe creator is a two edged sword. With updates it can be a real nightmare because the person who did the action isn’t the creator - and often they should be. Or it should be the “app”. Instead its always the recipe creator - who may not want all of the notifications from it, forcing them to shut off update notifications and such, including ones they want.

I see. Thanks Cody. Now I know to watch out for the notification load from recipes.