Description: When entering numbers containing both decimal points and commas in a cell, Calc applies unexpected number parsing rules. - Input: "1.2,333,444,555" -> Interpreted as: 12333444.555 - The pattern appears to: - Ignore all commas except the last one - Treat the last comma as a decimal separator - Remove any decimal points - Concatenate the remaining digits Additional examples: - "22.44,333" -> 2244.333 - "1.2,333e1" -> 123.33 Is this behavior by design or a potential bug? Steps to Reproduce: - Input "22.44,333" in one cell - Input "1.2,333e1" in another cell Actual Results: - "22.44,333" -> 2244.333 - "1.2,333e1" -> 123.33 Expected Results: Calc treat them as Text. Reproducible: Always User Profile Reset: No Additional Info: Version: 24.8.3.2 (AARCH64) / LibreOffice Community Build ID: 48a6bac9e7e268aeb4c3483fcf825c94556d9f92 CPU threads: 8; OS: macOS 15.0; UI render: Skia/Metal; VCL: osx Locale: en-US (en_CN.UTF-8); UI: en-US Calc: threaded
It depends on the locale setting. With en-US I can reproduce this, but not with locale cs-CZ. You can set cell format as text and then it will works.
I found this behavior is not uncommon. I believe it is a bug about how thousand sep . Here are the evidences: For en-US locale, comma serves as thousand sep. Maybe for Enurepo countries locale, dot serves as thousand sep. The behavior is a mixed thousand sep. Taking "1.2,333,444" as an example Every number representation related to thousand digit is affected, such as Scientific "1.2,333,444e-1", Percent "1.2,333,444%", Currency "$1.2,333,444" etc.
Please disregard the last comment, as it was an outline sent unintentionally. I’ve discovered a more serious issue in LibreOffice Calc. It appears that Calc incorrectly mixes thousand separators (dot . used in European locales and comma , used in the US) in numbers. It affects various number representations, including: - Scientific: "1.2,333,444,555e-1" -> 12333444.555e-1 - Percent: "1.2,333,444,555%" -> 12333444.555% - Currency: "$1.2,333,444,555" -> $12333444.555
Hello gplhust955@gmail.com, Thank you for reporting the bug. I can confirm that the bug is present in master. You can get around the bug by manually formatting the cell to be text. Version: 25.2.3.2 (X86_64) / LibreOffice Community Build ID: bbb074479178df812d175f709636b368952c2ce3 CPU threads: 22; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded and Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 19f3b72f34c487dc97d582712d21734a7e055fd5 CPU threads: 22; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded