Description: 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.
Created attachment 145158 [details] Document with userfields
i can confirm with attached document and Version: 6.2.0.0.alpha0+ (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
already reproducible with: Version: 5.4.7.2 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".
Reproduced in Version: 5.2.0.0.alpha0+ Build ID: 3ca42d8d51174010d5e8a32b96e9b4c0b3730a53 Threads 4; Ver: 4.10; Render: default; Version: 5.0.0.0.alpha1+ Build ID: 0db96caf0fcce09b87621c11b584a6d81cc7df86 Locale: ca-ES (ca_ES.UTF-8) Version: 4.3.0.0.alpha1+ Build ID: c15927f20d4727c3b8de68497b6949e72f9e6e9e Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a) LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
@Eike, do you have any idea why it might be happening ?
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.
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. @Miklos: Is that the only commit necessary or were there related/follow-up commits? Could you please backport the change to 6-1? Thanks.
Oh, right, it works fine in Version: 6.2.0.0.alpha0+ 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...
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.
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.
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.
(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.
Is there a way to speed up the fixing of this bug? Maybe with some kind of bug-bounty?
FWIW, this seems to be fixed since 6.2.0