This is great but the options do not match the current options. ‘Nov 19, 2025’ is missing, maybe others but this is the one I use in docs.
2 Likes
Erm, this has also been removed from the table options?!
There is now no option to show the shortened month with the date and year without the day of the week.
1 Like
Many thanks for the feedback, @Daniel_Robertshaw1!
We’re taking a look and we’ll share updates as we have them.
1 Like
@Bertrand_Bouteiller—we’ve made some updates, so please try again and let us know how that feels?
1 Like
Thanks @Ayuba_Audu, I just gave it a go and it looks much better now with the “31” in red but not corrected until we hit Enter. And going back to 30 instead of 1 also seems like a much more reasonable choice to me. All in all I’m pretty happy with the fix! 
2 Likes
@Daniel_Robertshaw1—many thanks for your feedback!
We had a few clarifying questions after digging in and we’d love to make sure we understand.
-
For the
MMM DD, YYYYdate format option, if you set the date order toMM/DD, you should see the option—see my screenshot below.
-
Let us know if that works for you? If you’d still want to use the
DD/MMdate order, with theMMM DD, YYYYdate format, we’d appreciate if you could share any details about the scenario.
-
The column configuration features both
DD/MMandMM/DDdate order options, so you should see theMMM DD, YYYYdate format option—see screenshot below.
-
Please let us know if you don’t see that date format option—you may have to scroll a bit more, as that’s unexpected.
Thanks again and looking forward to hearing back, cheers!
2 Likes
Hi @Ayuba_Audu any update about it ??
Hi, thanks a lot for the update. I’m sure it will be useful for many people. But what most of us are really desperate for (for years) is to be able to change the number format and be able to use the comma instead of the period. It is absolutely necessary. It is so important that, for our company, even though we want to use Coda, we have to use Notion/Excel exclusively for this reason.
1 Like
Hi @Jorge_Pineda,
Ayuba is out right now, but I’m happy to provide some context. We wanted to implement this change, but it turned out to be more complicated than we expected to ensure a high-quality experience.
As you are likely aware, Coda has a very rich and powerful formula language. When we examined changing the numeric input handling, we realized it felt quite broken that the formula language still expected users to write numbers with a dot as the decimal separator. To make the formula authoring experience consistent, we would need to develop a new formula parser with a different syntax, since commas are already reserved for separating parameters in a formula. The complexity increases further because we would need to build support to rewrite all formulas in any Coda document when a user toggled the number format setting in that document.
I know this isn’t what you were likely hoping to hear. That said, I’d love to gather thoughts from the community on whether they would prefer to deal with inconsistent experiences between data handling and formula authoring. I’m happy to bring this request back to the team.
6 Likes
for dates, is there ever going to be an option for users to select their own preferences? So that we can each view dates in a doc based on our own country’s norms?
1 Like
Hi @AJM,
I’m happy to share some context on this as well. This has been another particularly tricky point to navigate. The difficulty here comes from the fact that the presentation is also part of the data, if that data is used in certain calculations.
One common pattern we see across Coda use cases is constructing messages to send via email or Slack. When a date is part of that composed message we have to convert it to a serialization that we can send to an external system and this often means converting the date to a string representation. If we allowed every user to have their own preference instead of a unified preference for the document one user might see “Feb 6th 2025” but the message might get sent as 02/06/2025 which would be a bit confusing.
These same conversions can happen when data flows through the Coda formula language if a date is passed to a formula that expects a text.
4 Likes
It’s very kind that you are thinking that further into the localization of UX. It’s truly flattering.
I use Cyrillic, Latin and Greek characters with my 4 keyboard settings. Already have arthritis on my little finger for having to switch between keyboards 2-3 times a minute 
From that experience, I can tell you that you will probably never be able to achieve that doc makers can both create formulas and use the doc with the same keyboard. It’s like coding with Cyrillic characters - just not going to happen.
My localization expertise wants me to share that you have to focus on allowing the users (outside of the formula language) to enter and view required formats for:
- numbers
- thousand separator (comma, dot, space)
- decimal separator (comma, dot, space)
- dates (various short formats (dddd d MMMM yyyy), linguistically localised long formats (mercredi 20 février 2019))
- phone numbers (## ## ##; # ## ## ##; # ## #; # ## ##; (###) ### ## ##; +### ### ## ##, etc.)
- measuring units (cm, mm, km, inch) - with/without (non-breaking) space
- currency (before/after value and with/without non-breaking space)
- degrees
- percentages
- single- and double-quotation marks (« , “, ”)
- question- , exclamation-mark, colon, semi-colon, ellipsis (with or without (non-)breaking space again)
Note: Every space used in any of these should, in fact, be treated as a non-breaking space when viewing (when not editing the cell) to visualize it properly.
And don’t worry too much about the formula building language, at least for now.
Hope this is helpful.
4 Likes
Thank you very much for these detailed explanations. For me personally it’s very interesting to read about all the nuance of apparently ‘simple’ features. I’m sure it will make the wait more bearable to many!
6 Likes
Hi, @Jason_Tamulonis . This is so badly needed. I wouldn’t mind at all with these inconsistencies.
What is inconsistent for me is the need to remember all the time that, in Coda, you have to use dot instead of comma when entering data.
4 Likes
As the main DocMaker in my company it is a HUGE pain to not have the comma for decimal separator in my docs.
I had to change dozens of extra external spread sheets because of this.
I do my best to add number columns using the comma decimals pack (sorry don’t remember exactly the name of te pack).
If I don’t my employee and client get error messages All the time in their docs and I have to go thru and correct number all the time.
I have not rolled out Coda systems to more partners because I pf this pain…
It doesn’t matter how mano times you instructed people to use dot as decimal separators, onde the comma is right there I the keypad, they will instinctively type it… I can’t even help it.
It is one of the biggest drags of Coda to my users.
I do not have a perfect answer on how this issue should be handled (by account, by doc?), but am very open to volunteers a contributed in this talk.
I really hope we can find a good way to make this happen.
Thank for your interest in this topic as it is quite delicate.
5 Likes
Thank you very much for your detailed response. Until now, after several years, I hadn’t understood why Coda took so long to implement something that, in principle, seemed so simple. I think your approach is understandable but flawed due to being overly perfectionistic. Let me explain:
The issue we all have with number formatting is not related to the syntax in formulas—I don’t think anyone has ever requested that, since it would require a complete translation of the entire programming language, which, at least in my opinion, seems unnecessary. It should be understood that those writing formulas know perfectly well how the code and its syntax work. However, the problem arises with the users of these documents, for whom we do all this work (and for ourselves as well).
In other words, what we need is that when data is entered in the 1,000.11 format in a table, whether manually or copied and pasted, Coda understands that it is a number in that format, allows us to work with these numbers, and maintains the visual format while internally handling them in its standard format. This way, users can enter data without errors and view it in a format they understand, avoiding any confusion.
That’s all we’re asking for, nothing more. This is exactly what Notion does, for example: I can write numbers in the 1.000,11 format without any issues, perform calculations with them seamlessly, but if I need to write a formula, I must do so using the 1,000.11 format because, just like Coda, it separates programming syntax elements using commas.
In short, we are simply asking to be able to input and view numbers in the 1.000,11 format and work with them, ensuring that both inputs and outputs can be formatted without changing Coda’s syntax or internal logic.
In my particular case, and as I have been saying for years, we cannot use Coda across our entire organization solely because of this issue, so instead, we use Notion + Excel. The moment this feature is implemented, I would be delighted to migrate all our work to Coda, and I know many others would too.
You have an excellent platform. Removing friction for users in different regions would give you the real opportunity to reach millions of potential users who currently don’t use Coda because of small issues like this—including myself.
8 Likes
thank you very much for the transparency and context behind your challenges in implementing said feature. It means the world to us to be heard and definitely allows better understanding / empathy between users and Codans 
Agreed that it is not high-quality of an experience, but perhaps another way to look at it is…
there are far more “general” users of coda, then there will be makers. If makers know they have to use the dot in CFL, i think they are more likely to adapt than just the general users of coda which reading the many posts above - seem to be a non-starter issue for many organizations and ultimately non coda adoption.
Cheers!
Mel
7 Likes
Hello Jason, thanks for the details.
If it can help : I really don’t care if I have to type « 12.4 » in formulas as long as I can use « 12,4 » everywhere else. The major point here is to be able see and paste numbers in european format everyday in my docs, not the formulas (where I typically don’t use numbers but columns containing numbers).
Yes please, implement that formatting change
5 Likes
I also see the inconsistence in CFL as a non-issue. Hard coding values in formulas should be kept to a minimum anyway and even if we need to and we make a mistake, I guess it’s not too complex for Coda to implement a syntax error message to let us know.
5 Likes
Please, international numbers data format as well! Please, please, please, please
3 Likes
From my side too, as pointed out above, makers are a small number compared to consumers.
In SAP the consultants have long accepted that our interface into SAP configuration is not as smooth as that of the end-users.
P
3 Likes