Bug 134469 - Textimport gives wrong number if not at least 4 digits are given with a decimal
Summary: Textimport gives wrong number if not at least 4 digits are given with a decimal
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.4.4.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-07-03 08:39 UTC by michael.meisinger.mm
Modified: 2020-12-01 13:09 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description michael.meisinger.mm 2020-07-03 08:39:45 UTC
Description:
Hi All,

if I paste the following CSV data (the same happens if I open it from a file)

Tick#,offsetTime,IMU_ATTI(0):Longitude,IMU_ATTI(0):Latitude,IMU_ATTI(0):numSats,IMU_ATTI(0):barometer:Raw,IMU_ATTI(0):barometer:Smooth
49775263,-117.614,,,15,353.11334,353.121

The last number '353.121' gets imported as a decimal number without decimal point.
If I add a '0' at the end, '353.1210', everything is fine.



Steps to Reproduce:
Paste the following to Calc

Tick#,offsetTime,IMU_ATTI(0):Longitude,IMU_ATTI(0):Latitude,IMU_ATTI(0):numSats,IMU_ATTI(0):barometer:Raw,IMU_ATTI(0):barometer:Smooth
49775263,-117.614,,,15,353.11334,353.121


Actual Results:
49775263	-117614			15	353.11334	353121


Expected Results:
49775263	-117614			15	353.11334	353.121



Reproducible: Always


User Profile Reset: No



Additional Info:
see upper description

Let me know if you need additional info.
Thanx a lot
Comment 1 sora34ce 2020-08-05 17:52:52 UTC
Question: This is version 6.4.4.2 release, right? Because I tested it in version 7.1.0.0 and the error doesn't seem to work.
Comment 2 michael.meisinger.mm 2020-08-07 08:59:17 UTC
Yes, this appears in the currently installed version 6.4-4.2

did it get fixed/removed in the version 6 as well?
Comment 3 sora34ce 2020-08-28 17:18:08 UTC
(In reply to michael.meisinger.mm from comment #2)
> Yes, this appears in the currently installed version 6.4-4.2
> 
> did it get fixed/removed in the version 6 as well?

Yes, I think it was fixed in normal LibreOffice and LibreOffice Dev

Version: 6.4.5.2
Build ID: a726b36747cf2001e06b58ad5db1aa3a9a1872d6
CPU threads: 8; OS: Mac OS X 10.15.6; UI render: default; VCL: osx; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 4 michael.meisinger.mm 2020-08-31 06:12:17 UTC
If the column is defined as 'STANDARD' the number gets imported wrong. Maybe the '.' is removed since my Libreoffice is a german version and the location settings of my Win10 is set to a ',' as a decimal separator.
When I set the column type to Text, the number getting shown as expected.
The '.' is taken as 1000 separator, maybe thats the point which iritates calc?
Comment 5 michael.meisinger.mm 2020-08-31 06:14:26 UTC
I checked it with 
Version: 6.4.6.2 (x64)
Build-ID: 0ce51a4fd21bff07a5c061082cc82c5ed232f115
CPU-Threads: 8; BS: Windows 10.0 Build 18363; UI-Render: Standard; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: threaded
Comment 6 sora34ce 2020-08-31 17:25:58 UTC
(In reply to michael.meisinger.mm from comment #5)
> I checked it with 
> Version: 6.4.6.2 (x64)
> Build-ID: 0ce51a4fd21bff07a5c061082cc82c5ed232f115
> CPU-Threads: 8; BS: Windows 10.0 Build 18363; UI-Render: Standard; VCL: win; 
> Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
> Calc: threaded

Funny, my LibreOffice is the English version, and fi the column is on Standard or Text 353.121 still remains as is.

Version: 7.1.0.0.alpha0+
Build ID: 52820b52b3bca45e2db527d1cc5f4488b2e0b9d0
CPU threads: 8; OS: Mac OS X 10.15.6; UI render: default; VCL: osx
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 7 Mike Kaganski 2020-12-01 13:09:16 UTC
This is not a bug.

As michael.meisinger.mm correctly noticed in comment 4, this is related to the locale used for the import, and the decimal/thousand separators used in the locale. (However, note that OS settings for separators are not used in LibreOffice; whatever you define as separators in system, LibreOffice will use hardcoded comma as decimal separator for German locale, and dot for thousand separator.)

So the string "353.121" is a correct *whole number* in de-DE, while it's a valid *floating-point number* in en-US. "353.11334" is a valid floating-point in en-US, but it is not a valid number at all in de-DE, because the thousand separator is not separating thousands (groups of exactly three digits).

When you use German locale for CSV import (selected in the import dialog), "353.121" is detected as number, gets converted, and then is displayed using the default number format. "353.11334" is not detected as number, and thus is imported as text (and you may see the different alignment of the two cells in the result: 353121 gets aligned right, while 353.11334 gets aligned left; also View->Value Highlighting may help see the effect).

When you import CSV, you need to select correct settings. You may e.g. select en-US in the dialog's "Language" selector; or you may right-click and mark required columns as "US English" there (if you want them recognized as correct numbers) or "Text" (if you want them to stay text).