Bug 161756

Summary: Data table: dates are unmanageable in some locale combinations
Product: LibreOffice Reporter: Mike Kaganski <mikekaganski>
Component: ChartAssignee: Not Assigned <libreoffice-bugs>
Status: UNCONFIRMED ---    
Severity: normal CC: miguelangelrv
Priority: medium    
Version: unspecified   
Hardware: All   
OS: All   
Whiteboard:
Crash report or crash signature: Regression By:
Attachments: Screenshot at opening the sample file
Screenshot about how x axis a formatted in the file.

Description Mike Kaganski 2024-06-24 04:56:20 UTC
Configure your LibreOffice to use ru-RU locale, and en-US UI.

Open attachment 194920 [details]. In it, double-click the second chart to enter its edit mode, right-click its area and select Data Table.

In the table's bottom, see item 27, which shows "30.04.2024", so the date order is DMY.

Add a new line in the bottom, and type 29.04.2024 into Categories column, and 2,345 into the Y-Values column. Press arrow up.

Look at the chart. It updates, and the X axis changes its view: it starts to show points' labels for each point, in the form of "07/24/..." (the previous last point), and "29.04...." (for the new last point). Note how the new last point (for April) is at the end, after the July , while it is expected to show in the April, before June. See also, how the date format of the previous points is different from what is shown in the data table.

In the data table, edit the "29.04.2024" date, and re-type it as "04/29/2024" (so differently compared to the other points), and press arrow up. See how the chart updates, the X axis normalizes, and the new point's data is shown at the expected place. See also, how the data table's new point's category changes into "29.04.2024".

Generally, this behavior makes it simply unmanageable. The date entry expects en-US locale, but shows in ru-RU locale. The number entry expects ru-RU locale (the comma is considered the decimal separator; otherwise, if it would expect en-US locale, where the comma is thousand separator, the "2,345" would be treated two thousand three hundred fourty-five, and the value would be not in the 1-10 Y log range, but much higher - compare with simple "2345" entry).
Comment 1 Mike Kaganski 2024-06-24 07:55:31 UTC
I see this in Version: 24.2.4.2 (X86_64) / LibreOffice Community
Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2
CPU threads: 24; OS: Windows 10.0 Build 22631; UI render: default; VCL: win
Locale: ru-RU (ru_RU); UI: en-US
Calc: threaded

including safe mode

but I can't repro in master, nor in 24.2.0.3

so possibly some problem in the point release? likely WFM.
Comment 2 m_a_riosv 2024-06-24 23:26:48 UTC
Created attachment 194937 [details]
Screenshot at opening the sample file

What I see at opening the file with
Version: 24.2.4.2 (X86_64) / LibreOffice Community
Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2
CPU threads: 16; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win
Locale: ru-RU (es_ES); UI: en-US
Calc: CL threaded
Comment 3 m_a_riosv 2024-06-24 23:30:56 UTC
Created attachment 194938 [details]
Screenshot about how x axis a formatted in the file.

The x-axis is not formatted as the source data, it has their own format en-US.