https://bugs.documentfoundation.org/show_bug.cgi?id=161552
Mike Kaganski <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOTABUG Status|REOPENED |RESOLVED --- Comment #7 from Mike Kaganski <[email protected]> --- You had been given the explanation in comment 1. This works as designed; you made a mistake when opening the CSV, and your data was not recognized as dates already there, *because* it couldn't be a valid date in the locale that was used in your import dialog. Then the same strings were shown without apostrophes, again, *because* these strings couldn't represent a valid date (or other number) in the document's (cell's) locale, and as such, didn't need any decoration to disambiguate this string from a correct date. "26/05/2025" would be the same, if you put a string like "abc" or "12345/678/123456" there: these are not valid dates, nor could be confused with any valid number in Calc - so no use to add ' in front of it, you see that it's a string yourself. But then you decide to apply an US format to the cells with these strings. And suddenly, these same *strings* (yes, they are still strings; applying any formatting never changes the existing data - that's another spreadsheet basics that you should learn) *may* be confused with numbers *representable in those cells*. And that means, that Calc tries to help you: "this is a cell with en-US formatting; it has a string inside - but that string looks like a number valid in that cell; so let me show you, that it is *not* a number, but a text". And note, that this happens *exactly because Calc CAN recognize*, that this string may be confused / looks like / can be converted to a valid date now. This is closed. If you need to learn spreadsheet basics, you are welcome to ask user questions on sites like ask.libreoffice.org. Thanks. -- You are receiving this mail because: You are the assignee for the bug.
