Instead of potentially quite niche date calculations could some time be dedicated to localising date formats that reflect the use of the majority of the other 7.3bn people rather than the .3bn that the development team is part of? I am rather tired of teh pain that arises from forgetting to set every date column to be the correct format due to the absence of an account wide localised date format.
6 Likes
Hi @Sean_Sloan,
We definitely hear you on this and understand that itâs frustrating. Localization is something that we definitely intend to get to, but itâs also going to require a fair chunk of resources to make it happen. When we tackle it, weâll be looking at other aspects like currencies and numbers using commas or dots too.
The last bit to consider is that Coda is a growing product and there are still a few things that we are working hard on building out and timing of when to include which features plays a role in how efficiently we can make this happen. So we have to be strategic in which projects we bite off and when.
In summary, weâll definitely be getting to this at some point, I just donât have an ETA at the moment and itâll be a time intensive project when it does happen.
Thank you for working with us and for using Coda even when it doesnât fit your locale just yet! We greatly appreciate it!
Ben
1 Like
Nice⌠I DESPERATELY need a way to change the decimal separator to â,â (comma) and the thousand separator to â.â (dot). Iâm having so much headache because of that. PLEASE! This needs to be a top priority! Iâve had a lot of data wrongly inputted because of that. A lot of people might also need that:
And since a full localization is a big hurdle we need at least a way to set a default format (account wide or at least doc wide) for things like Dates, Currency and Numbers. Itâs a real pain to have to change it every single time I create a new column.
7 Likes
None of these new date related features are of any use if there is scope for induced errors in the recording of dates due to a lack of localisation. edit - not converting to user locale, but default document wide date format
What your comment relays, unintentionally I am sure, is that bells and whistles for American users are more important that consistency for anyone outside of the USA.
1 Like
Iâm sorry it read that way. As an example, think of creating 10 different styles first, then afterwards, anytime a feature is added it also has to work with 10 different styles. So the workload increases for every single thing added in the future. Whereas creating styles at the end, after more core features are in place, you have a much better scope of what you have to design for and can style in one go while also not having to work around it for each feature.
This is just an example of course, I know styling doesnât cause that big of an increase, itâs just to show the strategy thought process.
That said, we do know this is a priority for many people and we will get there.
2 Likes
How about instead of looking at the number of people who have complained about the number of seconds in a day being incorrect compare the number of people who have complained about the date format being a column based setting instead of an account level setting. It seems that the user benefit for getting this right is much higher than the user benefit of correctly calculating the number of seconds in a day. The seconds in the day may be easier to do but it has very low utility, people concerned about incorrect date calculations being a subset of people who use dates. This seems like basic Agile methodology. If the tool works correctly at the basic level i.e. it actually fits with non US users culture, then new features become a wow instead of a, âgreat dates are still US centricâ.
And if the suggestion is that the dates are being left to the end because they are hard to do, then they will never be fixed because realistically if your product is successful there will be no end.
1 Like
Sean,
I share some of your frustration, but there is a danger in assuming a new feature or improvement that arrives before another must there be higher priority. It is perfectly feasible that calculation improvement be fairly easy to implement thus it arrives sooner than a much more critical but complex one.
In truth we have no visibility of Codaâs real priority list, but we mustnât assume a priority based on which gets released first.
I could probably list 10 features that I would consider beneficial to all users, but there will another user who could list 10 more⌠many of which could be considered as pretty fundamental rather than âeye candyâ.
You are not alone in your frustrations, but on the whole, the team do seem to be aware of some big issues that need to be addressed and I have confidence that work is being done behind the scenes to address those issues.
It might feel as though some big issues are being brushed under the carpet, but I very much doubt they are.
19 Likes
I appreciate what you are saying, but the issue is not that I want some niche IBAN verifying code and am annoyed because a date calculation has been implemented first, I want a basic date to show correctly for my users, that is as fundamental a requirement as is possible.
So, out of curiosity, if a user is in the USA - are you going to assume that any USA user will want the date format the same way? For instance I am in the UK some UK users will want 2020-01-31, other will want 31-01-2020, other will want 31/01/20 etc⌠so already being the UK does not necessarily determine the format in which a specific user wants the date to be represented.
Should the document format dates according to individual user preference, or should the document creator make one assumptive date format per locale?
And what should happen if I am in the UK, but I need some dates to be in American format?
Maybe you could set a column to be âforcedâ into a specific format, or adopt one based on the userâs locale (ie - according to user pref)?
⌠already there are a lot of possible scenarios.
So when you (understandably) say you would like a basic date to show correctly for your users, what is âcorrectlyâ?
Excel STILL has this issue after decades⌠does the document creator determine the date format, or the document viewer - and what are the potential repercussions of assuming which date format to display? (there could be formulae assuming a specific format).
So - I totally understand your issue, but YOUR version of âcorrectâ wonât be a universally agreed version.
Itâs complicated.
P.S. I cannot even set a very common date format of 21-Jan-2020 without having to use a formula⌠itâs simply not one of the available presets, and I will also lose any date formatting if I copy a table into ExcelâŚ
These are also very basic features, but is my niggle any less important than yours?
We are just going to have to be patient, and just accept that what seems to be really basic issues that need to be addressed are probably being examined as part of a more complex issue - which is taking longer to resolve.
I can point you to many other users who consider better printing to be fundamental, or better permissions to be fundamentalâŚ
4 Likes
The difference being, and one I am sure you realise despite your straw man argument, is that you can select all and change the date formats in Excel everywhere they are used, you can even say for this file it will be ISO or some other layout. I did not dictate what the âcorrectâ format was, the correct date format is whichever one my users require, which if I could set at an account level, and not have to adjust every column it is used in, Iâd have a strong degree of certainty I was delivering.
1 Like
All replies here are all of the same topic and that topic is a request for localization of date formats, so Iâve moved them to their own place in the category âSuggestion Boxâ.
1 Like
Hi @Sean_Sloan,
from a content perspective you are totally right.
Nobody is questioning how useful is this functionality and how much this would be helpful.
On one side, I believe that the great effort required from Coda is to put in place features and and functionalities in a meaningful way from business, market, capacity, reputation, identity and complexity perspectives.
Which is easy to say.
Excel has been released exactly 35 years ago and it changed quite a lot since then.
Itâs a mature product that made the fortune of the company that built it, through steps that have been⌠well, controversial for a while (think about the 65K rows limitations way after that was a memory issue. I mean, years).
On the other hand, our big effort - the early adopters of Coda (which differs from Excel) - is to contribute in helping the product to become better and bearing the frustration with some patience and a constructive approach.
There are countless functionalities that would make my - and my usersâ - life way more better in Coda if implemented.
Function of this community is to collect suggestions and to help each other to find alternatives (more or less temporary) as the product will absorb them and keep on evolving like Excel did.
And itâs a really enjoyable (virtual) place for many.
So, if you need some discussion in order to overcome with this annoying issue, Iâm happy to listen to your actual use case and - perhaps - we can find some workaround.
I hope this helps.
Cheers!
3 Likes
The original issue with dates calculated as decimal numbers was actually pretty serious. Because of that issue, I couldnât trust formulas that would e.g. check on overlapping times for events, because oftentimes 4 AM + 1 hour wouldnât be <= 5 AM, but calculate to 5:00:01 or something like that because of rounding issues.
Anything related to localization, though, is super tricky, as other commentators said. Itâs especially tricky when you know how Coda handles formatted data â it stores it on the doc level, not user level. Hence column date format becomes universal for all users of the same doc. Localization would imply that each person would see their own version of the date, but itâs simply not technically possible yet. One interim solution would be allowing to select default date format for the doc (to automatically choose when creating new columns) akin to how one can select their default timezone for new docs. But knowing how Coda does features, Iâm fairly sure they wouldnât be happy to ship such a half-baked solution these days.
Thereâs a workaroundish way to approach user-specific date formats (albeit for display only) with user-specific settings and a FormatDateTime() formula with those specific values calculated at runtime (like here: PSA: You can have different users doing calculations with different values in the same rows). But yeah, itâs a workaround that uses a hidden formula, so not recommended really. Iâd only do this if the client insisted they wanted this.
3 Likes
I donât doubt that is an issue, but tell me what date is this 01/12/20. The scope for error is almost a whole year.
That is all I am asking for.
3 Likes
Judging by the leading zero, itâs Dec 1 in European format. But I see your point.
I hope that everybody at Coda is aware that I canât use a tool in a global team when there is confusion about the date format. No need to make things complicated. just give the option to change the format (per table or per account) or you will exclude many customers.
4 Likes
- We are still waiting for this. We really need numbers and currencies localization.
We canât use Coda in our organization because of this.
4 Likes
why would the leading zero indicate that date
it is totally ambiguous
it could be EITHER 1st December 2020, or 12th January 2020, or 20th December 2001, or âŚ
ANY combination of the three numbers assigned randomly to day, month and year
only when one or more of the numbers is >12 and/or >31 does the parameter space get reduced
there is a reason we have ISO standards for things like this
and it has been several YEARS now since these issues were first raised
so i can understand folks getting impatient
i am using formulas where necessary but that results in Text data types
max
3 Likes
@BenLee it has been 2 years⌠any update??? I mean standard number and date formatting would be nice⌠btw notion has itâŚ
2 Likes
Hi @anon47149808,
Looks like youâve received replies to your other bumps on this topic already, but Iâll offer another so that you know your thoughts are heard.
We definitely want to add this and we are a company with employees who come from all over the world, so this is known and felt internally as well. But we do have to find the right time to add it and make sure we add it properly. There is quite a bit of complexity to it and more that will be affected than what is obvious, so we need to make sure we can account for everything before throwing engineers at it.
We do hear you and I wish I could tell you more at this moment, but even with as fast as we grow our feature set and capabilities here, it still does take time.
3 Likes