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.
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!
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.
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.
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.
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.
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.
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.
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…
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.
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”.
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.
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.
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.
Judging by the leading zero, it’s Dec 1 in European format. But I see your point.