Launched: Time Zone Improvements

We’ve been working for quite a while to address your feedback about shortcomings for Time Zone support in Coda, and I’m excited to share that today we’ve launched a much improved, more comprehensive Time Zone coverage! We hope this helps previously impacted users a lot, especially with Date & Time Formulas, as well as other Automations and rules.

If you signed-up for Coda and created your account after the date you see this Community Post publishedーgood news! No action should be required on your part.

For our existing users, please be advised that a manual change is required if you have been working with Coda in a previously unsupported Time Zone.

First, change your default Time Zone at coda.io/account so that new docs moving forward will honor it.

Then, for any existing docs, you can update your doc settings to your preferred Time Zone using the doc settings right-side panel.

. . . and then you’re all set! Thanks for helping make the Maker community a truly global one, and for sharing your valuable feedback with Coda!

ー Jason

20 Likes

Hi @Jason_Tamulonis, Thanks for the update :slight_smile:
I’m curious about worldwide users of apps
In my case i’m in italy and my app will be used mainly in the US (but not only).
How should i set the timezone?
Right for me or for us citizen? or for asian ones?
What should i tell to those users for set up their doc (one doc for every user approach)?
Is that really better than before?
P.s. i’ve had the worst time on coda with dates, they was behaving with their own logic, does that update fix those aspect?

Thanks :slightly_smiling_face:

1 Like

Hi @Mario

Thanks for the question, let’s see if I can help.

This is really going to depend from use case to use case, given Coda is a completely collaborative doc you have to pick one timezone for the entire doc. Currently only our Calendar and Gantt views offer the ability to show dates in the viewer’s current local timezone. In the future we might want to explore more options here. In general you will want to set the document’s timezone to that of the primary user or wherever the majority of users are.

This update was more about adding support for a number of timezones that were completely unsupported before, and how we handle transitioning from one timezone to another. The way dates behave in Coda has not fundamentally changed with this update.

I’m sorry to hear that. Generally speaking whenever something isn’t behaving the way you would expect the team would love to hear about it. Feel free to reach out to me or anyone on our support team.

2 Likes

Thanks for the reply @Jason_Tamulonis! :blush:

My user base would come from potentially all over the world, for those types of doc having just one “fixed” reference timezone is a little limiting, but it is for sure an important step forward for most coda use cases! :blush:

Regarding the behaviour of dates columns and formulas on coda, every time i have to deal with dates operation (like sum days), or compare dates (between different columns), or importing dates (also pasting those sometimes do not work, in a column a date is valid, in the adjacent one is not valid, both formatted in the same way), or formulas with lists of dates inside, or sorting those rows, often work unexpectedly, for my specific use cases i’ve found workarounds, but new users will have to fight with those (maybe just european one, i do no know…)
I frankly divide the formula in more subcolumns easier to formulate, and then i can understand why some dates are interpreted in “strange” ways, and correct those with other formulas, but it’s tricker than what is needed :exploding_head:

Hi @Mario,

Do you have an example doc of where this is happening so we can try to re-create the issue?

Hi @BenLee :slight_smile:
Thanks for your interest in this case, i have in my main doc a table in which i save weights of pets, the table is organized like that

The first column is Name,
the 2nd and 3rd are the weights,
the last 2 columns are respectively the date in which a weight is saved AND then the date in which a weight is not more valid
The last one is made using a formula that take the date below the thisrow.validfrom (if exist, if not, today()) (i’ve lost 3+ hours on this :exploding_head:)

Screenshot 2020-03-21 at 12.26.10

I do not have time to prepare a sample doc because it will take a long time, i’ve had hard times creating that last formula, you can try to recreate it if you dare ahahahahah :slight_smile:

No, seriously, i love to help coda team digging into strange behaviours, but i’ve already 2 or three “bug report” open and it take some times for me to prepare all the material ecc, and in this specific case i’m pretty sure that recreating that formula will show some unexpected reactions

I also think that the italian way of writing dates could mess things up (no idea why)

For me its normal to say the day, the month and the year, it seem really logic, why i should start with year, then day, and then month? and what if i have 2020/03/04? is this third of april or fourth of march?
in any case those are there probably because someone could need those, so…
Also, if you have one column with a date like “1/2/2020”, and it is valid in that column, if i copy it and i paste it in another equal column (formatted as a date, with the same type ecc) it become “not valid” (with the upper left angle red)
My idea is that coda manage those data as epoch, and then convert those just when displaying, but it’s just a tought…
Let me know if you are able to recreate the issue, in case not, i’ll prepare some sample in the future!
Thanks in any case

1 Like