Date and Time design is incorrect

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



Totally agree with you here as I am currently facing a similar issue with the date and time.
I find the current implementation of the date and time very flawed and presents so many issues than it was intended to solve.
The devs might have had good intentions on converting a date to the current user’s timezone but it current state through the API is difficult to work with if not dangerous.

For example, if you change the timezone in your profile to another timezone (for test purposes) and then query the date in the playground, not only takes into consideration your timezone in your profile but also your current device location.
This results in a very confusing set of dates.

Proposed solution. Give dates and times “as is” in the board in UTC format and update dates “as is” in UTC format. If a developer wants to do any conversion, they will do it themselves anyway and there is no need for to convert dates based on user’s device location or timezone


Hello everyone,

Thank you for the feedback about how our system handles dates and times.

I understand your frustration and I have prepared a report for our team to take a look into it that includes your comments and suggestions.

I will share any feedback I get from the team with you :slightly_smiling_face:


Hi @Matias.Monday,

Thank you for taking this seriously and the time to understand it and compile a report.

I would have been very happy for it to be handled via the internal support channel instead of having to post here, but I wasted about a day in effort trying to convince the support team that it is actually a problem and a serious one at that.

I am looking forward to a speedy fix and who knows, a legit date/time storage method might even open the door to making the simple but long outstanding change of adding and times to timelines, a start and end time to date fields, or even a proper calendar in


Hello again @Mitch.Poyser,

I am sorry that was your experience. I am not sure who you reached out to previously, but just in case, you can always send us an email regarding the API or the apps framework to That will get you to our tech support team directly.

I will share any updates I have regarding this here!