https://bugs.documentfoundation.org/show_bug.cgi?id=148747
--- Comment #37 from ady <[email protected]> --- > If I change the local setting to English, the apostrophe suddenly appears in > the D1:O1 cells, but when I change to Czech it disappears again. Finally we can see one important factor that makes the difference in our reported experiences. The real question to solve all this is _what_ exactly made older version in Czech to behave as they did whereas newer versions behave differently, making this file fail when they worked before. The change in behavior might be intentional, or might be a bug, but we don't know yet what provoked this change. We also have a locale factor here, when LO in English behaves one way, whereas in Czech it behaves differently. The results of formulas shouldn't be different just because of LO language. These two factors are the reason for me to think that this should not be set as NAB at the moment. Something happened; and the fact that the formulas are not ideal are not relevant in this case, IMO. And @raal thought this too, according to his comments here and in ask.libreoffice.org. > When I switch Locale settings to English, the "Date acceptance patterns" is > set to "M/D/Y;M/D" and this changes the display of dates in the statement, > so then the "calculation" sheet cannot calculate anything. If I set the > English pattern to "D.M.Y;D.M.;D. M.;D. M. Y;D. M.;D. M. Y" , it stays in > the settings, but the date display does not change. "D.M.Y;D.M.;D. M.;D. M. > Y;D. M.;D. M. Y" will only stay there until I switch to another language and > put it back. Then it's back to the original "M/D/Y;M/D". Please don't mix these features. One thing is what Calc will automatically interpret as a date when introducing a value in a cell. Another thing is the cell's format, which can be changed in several ways. If I have a date in a cell that is displayed as "01.2023" (without quotation marks) and it is displayed as "MM.YYYY", I could change the cell format to something else, such as "MMM YYYY" for example. As I tried to express before, we need to focus on the changed behavior(s), whether they are about the locale in cells, UI language, OS's settings, or some change in some version of LO. Things that seem to be not relevant in this specific bug report, such as how the formulas are built, or how to display a date (e.g. with or without leading zero) should not be a factor to set this report to NEW. > If I overwrite the values with an apostrophe to "01.2022", it switches to > "1.2022", it doesn't stay there "01.2022", but that wouldn't help me anyway, > because the dates in the listing have changed to "D/M/YYYY" because of the > Locale setting, which can't be changed. > > > So I can't replicate the fact that when I overwrite the cell with the > apostrophe to the same value, it suddenly starts counting correctly > (non-zero values appear). I can also simply delete the apostrophe, leaving the "1.2022", and the resulting formulas change to non-zero. It is certainly intriguing why you are not able to see the apostrophe when the UI is set to Czech. This is independent of the formulas. Another clue that this must be investigated, instead of setting to NAB. I can only hope that either raal comes with some explanation, and/or Miguel changes his mind, and/or someone else can replicate this with some kind of relevant logical explanation as to why this changed for Czech UI in version 7.2, whereas in English the behavior is a fail with older and with newer versions. -- You are receiving this mail because: You are the assignee for the bug.
