Bug 120112 - Wrong values shown in Userfields after changing Locale setting
Summary: Wrong values shown in Userfields after changing Locale setting
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
Depends on:
Blocks: Fields
  Show dependency treegraph
Reported: 2018-09-25 10:36 UTC by florian-adamus
Modified: 2019-06-20 12:42 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Document with userfields (9.68 KB, application/vnd.oasis.opendocument.text)
2018-09-25 10:37 UTC, florian-adamus

Note You need to log in before you can comment on or make changes to this bug.
Description florian-adamus 2018-09-25 10:36:07 UTC
In a document with userfields for timestamp and float values changing the locale setting from German(Germany) to English(USA), restarting Libre Office and updating the fields by pressing F9 leads to wrong values for all userfields.

Steps to Reproduce:
1. Set Libre Office locale settings to English(USA)
2. Restart Libre Office
3. Open the attached libre office document
4. Press F9 to update the fields

Actual Results:
The value of the timestamp field is wrong (year -3741) and the values of the other userfields are multiplied by 1000000.

Expected Results:
The userfields should show the correct values.

Reproducible: Always

User Profile Reset: Yes

OpenGL enabled: Yes

Additional Info:
The user fields in the attached document were created after the Open Document Format for Office Applications (OpenDocument) Version 1.2 by an external tool.

Userfield declaration:
<text:user-field-decl office:value-type="date" office:date-value="2017-09-14T16:09:46" text:name="WW.Timestamp.Protocol.Close"/>
<text:user-field-decl text:name="T__9.actual" office:value="27.048431" office:value-type="float"/>

Userfield usage:
<text:user-field-get text:name="T__9.actual" style:data-style-name="N107">27.0484</text:user-field-get>

When double clcking one of the user fields the value shown in the property window is still correct, even after updating.
Comment 1 florian-adamus 2018-09-25 10:37:24 UTC
Created attachment 145158 [details]
Document with userfields
Comment 2 Oliver Brinzing 2018-09-25 16:57:18 UTC
i can confirm with attached document and

Version: (x64)
Build ID: add7d506b9ef9b799aefbbae1270642991b15668
CPU threads: 4; OS: Windows 10.0; UI render: default; 
Locale: de-DE (de_DE); Calc: threaded

steps to reproduce:
- open attached document
- press F9 - userfields will still show: 15:18 09/17/2018
- change "Locale setting" in "Tools/Options.../Language Settings/Languages"
  from "Default German (Germany)" to "English (USA)"
- press F9
- userfields will show: 00:00 12/20/-3741
Comment 3 Oliver Brinzing 2018-09-25 17:04:22 UTC
already reproducible with:

Build-ID: c838ef25c16710f8838b1faec480ebba495259d0
CPU-Threads: 4; BS: Windows 6.2; UI-Render: Standard; 
Gebietsschema: en-US (de_DE); Calc: single

a restart is needed after changing "Locale setting".
Comment 4 Xisco Faulí 2018-10-17 14:54:25 UTC
Reproduced in

Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53
Threads 4; Ver: 4.10; Render: default; 

Build ID: 0db96caf0fcce09b87621c11b584a6d81cc7df86
Locale: ca-ES (ca_ES.UTF-8)

Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e

Version (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)

LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-
Comment 5 Xisco Faulí 2018-10-17 15:03:23 UTC
@Eike, do you have any idea why it might be happening ?
Comment 6 Eike Rathke 2018-10-18 11:25:38 UTC
Interesting.. ;-)

I don't know yet why but what seems to happen.. the document's user field for the date for example is

  <text:user-field-decl office:value-type="float" office:value="43360.6375231481" text:name="WW.Timestamp.Protocol.Close"/>

which added to the null-date and displayed as en-US date+time yields the expected 15:18 09/17/2018

Once the locale was switched and F9 recalculated yielding in 00:00 12/20/-3741 saving the document shows

  <text:user-field-decl office:value-type="float" office:value="433606375231481" text:name="WW.Timestamp.Protocol.Close"/>

that value apparently has the decimal separator removed, which results in a large value that for date calculation causes some component's integer field to wrap around resulting in a negative year.

My guess is that Writer at some point tries to interpret the floating point value as string instead in a German context, in which the '.' dot is a group (aka thousands) separator, which is ignored.

Same for the other user-field-decl that have floating point values and recalculation effectively strips the decimal separator yielding a large integer value.
Comment 7 Eike Rathke 2018-10-19 12:13:08 UTC
FWIW, this works correctly in master/6.2 and seems to have been fixed with https://gerrit.libreoffice.org/58492 which likely can be cherry-picked to 6-1 but needs to be backported because sw/qa/extras/layout/layout.cxx can't be merged as is, either merge conflicts need to be resolved or the unit test part omitted.

Is that the only commit necessary or were there related/follow-up commits?
Could you please backport the change to 6-1?
Comment 8 Xisco Faulí 2018-10-19 12:28:02 UTC
Oh, right, it works fine in

Build ID: 5fb66ae5595b7435e8954df31473fad15a74b8c2
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: en-US (ca_ES.UTF-8); Calc: threaded

in comment 4 I didn't test it in master as it was already done in comment 2.

Note to myself: always double check things in master...
Comment 9 Eike Rathke 2018-10-19 13:42:05 UTC
So this is still fouled up.. it now works when loading in an en-US locale, but it does not work when loading in an de-DE locale and then switching to en-US and F9 recalculate, as lined out in comment 2.
Comment 10 Eike Rathke 2018-10-19 13:45:20 UTC
Note that comment 2 tested with
Build ID: add7d506b9ef9b799aefbbae1270642991b15668
which was committed on 2018-09-25 and thus included 6ca5d288ca810f128163da121777ee2e11c46edc from https://gerrit.libreoffice.org/58492 committed on 2018-08-02.
Comment 11 Eike Rathke 2018-10-19 13:49:35 UTC
I think the underlying problem is that Writer seems to remember the field content in the context of the table cell as string and tries to reparse it, instead of using the actual numeric value and only format that for display.
Comment 12 Miklos Vajna 2018-10-19 13:57:18 UTC
(In reply to Eike Rathke from comment #7)
> @Miklos:
> Is that the only commit necessary or were there related/follow-up commits?

I think this was the only commit.

> Could you please backport the change to 6-1?

As you found, the above commit only fixed the scenario tested in SwLayoutWriter::testUserFieldTypeLanguage(). I would suggest keeping this bug open till the post-startup locale change also works. I don't have strong opinion if backporting my fix to libreoffice-6-1 is useful or not till this bug is not fixed on master.
Comment 13 florian-adamus 2018-11-22 14:48:44 UTC
Is there a way to speed up the fixing of this bug? Maybe with some kind of bug-bounty?
Comment 14 Eike Rathke 2019-06-20 12:42:29 UTC
FWIW, this seems to be fixed since 6.2.0