Launched: Doc time zone

For too long, times in Coda have been stuck in U.S. Pacific time. Today, we’ve launched a feature that allows you to set the time zone of a doc.

Formulas in a doc like Now() and Today() will now return in the doc time zone rather than Pacific, and time-based automations will run according to the doc time zone.

Values input in cells will also be stored in the time zone of the doc. New Calendar and Gantt views will also now display in the doc time zone by default, ensuring a consistent view of time-based data in all views and for all users of the doc.

Existing Calendar and Gantt views that showed in the time zone of the current user will not change unless you decide to update them to the doc time zone, and this remains an option for these displays.

We’ve also added new formulas so you can access the doc time zone as well as the user’s current time zone: DocumentTimezone() and CurrentTimezone().

Each user can choose a default time zone for new docs they create. By default, this is set to their local time zone if it’s supported.

Supported Time Zones

This update supports a wide range of time zones, including most time zones in North America, Europe, Australia and New Zealand as well as select other regions worldwide. Due to complexities in time zone data, certain time zones are not yet available. If your specific location is not in the list, you may be able to choose a different location in the same time zone, or an alternative location with the same UTC offset.

Try it out, and read more here: Change your doc’s timezone

25 Likes

Thanks Nathan, any idea when support for “Doc to Doc” lookup is coming?

1 Like

Amazing, dates have been driving me up the wall recently so this great to see.
The other side of the coin is being able to enter dates in dd/mm/yyyy format in the cells rather than it always falling back to the US mm/dd/yyyy format. Hope that comes soon too.

8 Likes

Agreed. Also, localized dot vs comma notation would be nice. Over here we are used to the dot as thousand seperator, while using the comma to seperate integers from decimals (i.e. vice versa to the current implementation).

5 Likes

I can say a lot about the localization of numbers and units. I am sure Codans are aware of the need of that. A custom format for many of the column types is quite necessary as currently currency, numbers, dates, punctuation (e.g. use of non-breaking space for FR) are all areas to be improved if the idea is to use the prepared layout for app :slight_smile:

Stefan Stoyanov
Localization project manager

I send you this email from my iPhone

4 Likes

Finally! Great update.

@nathan, what about changing first day of the week in the setting? It is very strange to have Sunday by default as the first day of the week.

Sergey

9 Likes

Hi all,
Thanks for the comments! These are all excellent requests, and we’re aware of areas that still need better localization support.

@Rob_Claisse, if you first set the date format for a date column to dd/mm/yyyy, you should be able to enter dates in those cells in that format. Here’s an example:

calendar

1 Like

@nathan thanks and I do this sometimes but it restricts you to using that very specific display format for your dates. If you want dates to be show in say Sun, Apr 14 then you have enter dates in mm/dd/yyyy even if previous you had the date format set to dd/mm/yyyy for the cell. So its still restrictive and confusing people for people, it doesn’t make sense that just because I want my dates displayed as Sun, Apr 14 that I have to enter my dates in odd way that the US people do :wink:

Way better to do as Gsheets etc do and have a document wise setting for locale, much like you have for the timezones and we can pick a format or a country and then you default date entry and currencies to that locale.

Thanks! Very helpful to get the details. With the doc time zone, we’re starting to create a place that we can use for future doc settings like this.

Hi @nathan, I have some automations set to PDT and there doesn’t seem to be a way to change these. Is there an option?

Hi @Stefan_Stoyanov, all automations will run in the doc time zone.

If you change the doc time zone, the automations will by default stay in the same numeric time but now run in the same time zone (so what used to run at 9am PDT would now run at 9am EDT). If you want to also adjust the time, you can do so from the automation pane.

Here’s an example: https://cl.ly/3bb6f4dcd980/Screen%20Recording%202019-04-23%20at%2011.24%20AM.gif

Does the automation have to turned off, or something? I am selecting EEST time zone for the document. However, in the automation I see PDT. I tried to change it there, but still PDT

Thanks for alerting us - I can now reproduce this as well in certain docs, and we’re following up to investigate.

@nathan @Stefan_Stoyanov I’m getting the same issue here as well, although I’m attempting to change to CST.

Hi @Stefan_Stoyanov @Josh_Szwarga

We have identified the underlying bug that was causing the change to not apply in some cases on existing automations. The fix should roll out by tomorrow afternoon (Pacific time). Once it does, the timezone for Automations will change when you change the document timezone.

In the meanwhile, you can manually fix each automation by changing the When of the automation to be based on row changed, and then back to the time based trigger. This would set the timezone to be the same as the document.

Sorry about this issue, and thanks for reporting it.
Himanshu

1 Like

Thank you @Himanshu!

We can wait a day to release that fixture and then will fix the document :slight_smile:

Thank you!

Great update! but there are a few time-zones missing. Hope they get added soon. GMT +4:00 please :slight_smile:

1 Like

Hi Nathan, not sure if you got this but was asking when you believe Doc to Doc is coming up?

Hi @nathan, it would be great if you could add a timezone for UTC+4. Thanks!

2 Likes

this would be great for the rest of the world outside the USA