Coda has a concept of “document time zone” that allows you to select the time zone that a document will use for dates and times. But this is not really very helpful if what I need to do is display dates and times in the time zone of the user viewing the document. In fact, JavaScript has wonderful tools (such as the toLocaleTimeString() function) which can be used from a Coda pack to help facilitate automatic time zone conversion. I have created an example Coda doc with such a pack used to convert dates and times to a chosen time zone.
However, there is a problem. Coda does not report the locale or time zone of the current user anywhere that a pack author could find that information. This data is shared with Coda from the user’s browser, but Coda never passes this along.
At first this seems reasonable, after all, Coda docs and formulas are run on the server-side, so the locale or time zone of any particular user is not known by the server at the time it runs and caches the formula. But as my example doc demonstrates, we can use a personal control to hold the time zone value and that personal control value will be different for each user encountering the document. Somehow Coda does the right thing and shows the correct time zone to each user if they take a moment to select their time zone in the personal control.
If that is the case, why can’t Coda create a pseudo-personal control that we could use to pass data along to the pack? There could be a “browser” control that always contains certain values passed along by the browser the current user is visiting with, values like locale and time zone that could help us create much better user experiences?
Am I missing something fundamental about Coda? It really seems this is structurally possible. Does Coda not provide access to this data for privacy reasons or technical reasons? If for privacy reasons, I really think Coda should reconsider for at least the locale and time zone values. If for technical reasons I really wonder if this could not be implemented as something technically equivalent to personal controls.
Is this what you’re looking for? This is the Pack’s context. I haven’t tested the origin or influence of this value, just thought I’d make this observation in case you were unaware of it.
Yes, Bill, I also got excited when I saw that in context.timezone, however, Coda’s documentation states that this is “The timezone of the doc from which this formula was invoked.” So in other words, this is not the user’s time zone at all, but rather the document’s time zone.
What I need is the user’s time zone and locale as described by the user’s browser in the header information of the user’s request for the Coda document.
Yep - understood.
This is such a fundamental and core tenet of building web apps, I cannot understand why this is not exposed in the formula language.
I asked a few questions in my initial post, but no answers at all from Coda developers. I am new to this Coda community, do the developers monitor and respond to items here? If not, where should I ask questions instead?
Hi Eric, I am on the engineering team. We do monitor the community and try our best to respond promptly. I apologize for not getting back to you sooner.
Regarding the specific feature you are describing, you are indeed correct that there is no technical limitation preventing us from exposing the timezone and locale reported by the current browser. The honest answer as to why we do not have this functionality today is that it hasn’t come up frequently in the feedback from our users. However, I can certainly think of solutions that would benefit from this, and I will add it to our backlog for consideration.
Thanks
Himanshu
4 Likes
Thanks for the response, Himanshu. Coda is a great tool, I hope it keeps getting better. I know access to user time zone and locale would help me build better Coda docs. I appreciate your consideration of this for the backlog.
i have built a pack formula for a client that returns the users timezone
(but the users locale is not available from a pack)
i will publish the pack and put a link to it here in the morning (in the CET timezone)
max
You can get the current users timezone without any packs. You can just use coda formulas.
And then you can use some formula logic to transform every time in a doc to the current viewers timezone
The coda school has some documentation on this - let me see if I can pull it up.
@Scott_Collier-Weir, I would love to see that. All the documentation I have found indicates that you cannot get the current user’s time zone, but only the current document’s time zone.
@Xyzor_Max, if this can be done from a pack, that would be great. But I ran into the same restriction when I tried to write a pack to do this. I could only, actually, get the document’s time zone and not the time zone being reported by the actual individual’s browser. If you make a pack that can get the individual’s time zone, could you please also share the source code of the pack? Thanks!
Here let me know if this helps
And here’s a look behind the scenes at those formulas
2 Likes
Ah, Scott, that is very helpful!
CurrentTimezone() does seem to have the information I need.
Now all I need is something like CurrentLocale() or for Coda to add a locale attribute to the CurrentTimezone() response.
Thank you!
Wow. This looks amazing. I don’t have time or budget to take the course, but I wish that I did.
One crazy idea - a 7.5 on the technical scale.
- Create a web widget on ValTown that serves up something innocuous like the time, or date.
- In that widget (a NodeJS web service), capture the locale, and persist it with a user session ID into the widget’s local storage.
- Render the widget in a Coda page as an embed.
- Query the same widget (using a Pack calling an express method) to get the locale from the widget’s local storage.
- Take a shower because you’re going to feel very dirty doing all this just to get the locale.
1 Like
So if I understood this thread correctly, the document timezone is UTC and the CurrentTimezone().Offset() is used to display dates to the users.
But how do you deal with summer times? If a task was created in summer when the offset was 2 (in Europe) but now in winter the offset is 1, all the dates will be incorrect unless you consider which offset was valid when the task was created…
Timezones are a beast ^^ Keep it as simple as possible, you’ll never be able to deal with all edge cases
1 Like
…