I’ve hit a wall with trying to get action via the support team so I’m trying here.
The Date and Times for the Date columns are being returned from the api in the format: yyyy-mm-dd ##:##
This is a big problem considering date/times standards have been around for over 20 years:
https://www.rfc-editor.org/rfc/rfc3339
Monday.com is accepting (only) UTC values, then converting them in a mixture between UI and API (without the ability for the user to intercept it before then) to the loosey-goosey format above that is impossible to tell what it actually is without having to query further context, without the ability to intercept it.
This is super strange and becomes a real issue when it is coupled by the next strange idea of Monday.com automatically changing your time zone on your profile to match your physical location. With no opt-out or opt-in ability.
I set up integrations (webhook to a JS script) on a service account and then went overseas. I was setting different integrations up when I was alerted to the fact our entire payroll and numerous other things were 2 hours out of sync. This is because I logged in to a time zone with a two hour difference and therefore all values across the entire integration setup were being silently delivered yyyy-mm-dd ##:## (-2) due to referencing my profile value that was automatically updated.
It is a kick in the teeth that in the api returns the updated time of the date field in ISO8601 standard but the actual date is in a format derived by someone who has never met the internet before.
As I type this I can see that a first pass of corrections were performed on the application to make it more (ISO8601) standard but inexplicitly the most important column seems to have been missed (?): Date-time API change
At a minimum can we please have the API returning ISO (even just in a new key pair or additional info to allow a light touch roll out)? Or even just access to the UTC date for the date/time columns so that I can build out the applications knowing what time the column is actually referring to.
There should also be an opt in option for the profile time zone as an interim measure.
It doesn’t make any sense that it is both a selectable dropdown and automatically updated by location.
Because what is the point of selecting something that will be overridden at log in, it just creates confusion.
I don’t like the idea of never being able to log into an account (that owns the integrations) in a different time zone, nor do I like the idea of my code going to the profile of the account and reading the time zone and converting every date and time I extract according to whatever the time zone difference is from where I am to the organisations location (only ever the one location).
Thanks,
Mitch
