Bug 161361 - Editing a User Field of type date has inconsistent localization
Summary: Editing a User Field of type date has inconsistent localization
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
24.2.0.2 rc
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Fields
  Show dependency treegraph
 
Reported: 2024-05-31 11:19 UTC by Colin Pitrat
Modified: 2024-11-30 16:56 UTC (History)
3 users (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 Colin Pitrat 2024-05-31 11:19:01 UTC
Description:
I'm using LibreOffice 24.2.0.2.

In Writer, in a new document, do "Insert > Fields > More Fields" (or Ctrl+F2).

In the tab "Variables" select "User Field", provide a name, click on "Additional formats".
Select language = French then select Date and pick any format (let's say "JJ/MM/YY" which is french for "DD/MM/YY").

Provide a value (e.g. "10/05/2023") then click Apply and Insert. This inserts the provided date and it's even possible to change it (e.g. "03/31/2023") and click Apply. Click Close.

So far, everything work as expected.

Now double click on the field. You can edit it. Try setting it to "10/07/2023". The value actually taken is "07/10/2023". This has the funny side-effect that clicking on Apply multiple times keeps changing the date between July 10th and October 7th.

Try setting it to "21/07/2023" (21st July 2023, remember this should be DD/MM/YY). This fails.

Obviously this field expects a date with the format "MM/DD/YY" which is inconsistent with the way the previous dialog was working and is also very surprising for users.

The fact that many dates won't work and that there's no error when it fails to parse the data makes it even more confusing.

Finally, from this same dialog (from double clicking on the date field), changing the Format doesn't work.



Steps to Reproduce:
In Writer, in a new document, do "Insert > Fields > More Fields" (or Ctrl+F2).

In the tab "Variables" select "User Field", provide a name, click on "Additional formats".
Select language = French then select Date and pick any format (let's say "JJ/MM/YY" which is french for "DD/MM/YY").

Provide a value (e.g. "10/05/2023") then click Apply and Insert. This inserts the provided date and it's even possible to change it (e.g. "03/31/2023") and click Apply. Click Close.

So far, everything work as expected.

Now double click on the field. You can edit it. Try setting it to "10/07/2023". The value actually taken is "07/10/2023". This has the funny side-effect that clicking on Apply multiple times keeps changing the date between July 10th and October 7th.

Try setting it to "21/07/2023" (21st July 2023, remember this should be DD/MM/YY). This fails.

Obviously this field expects a date with the format "MM/DD/YY" which is inconsistent with the way the previous dialog was working and is also very surprising for users.

The fact that many dates won't work and that there's no error when it fails to parse the data makes it even more confusing.

Finally, from this same dialog (from double clicking on the date field), changing the Format doesn't work.

Actual Results:
Date is parsed as MM/DD/YYYY but displayed as DD/MM/YYYY.

Expected Results:
Date should be parsed the same way as it is displayed, ideally according to the format chosen by the user.


Reproducible: Always


User Profile Reset: No

Additional Info:
N/A
Comment 1 Robert Großkopf 2024-06-15 09:24:58 UTC
Have tested with

Version: 24.2.4.2 (X86_64) / LibreOffice Community
Build ID: 51a6219feb6075d9a4c46691dcfe0cd9c4fff3c2
CPU threads: 6; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb)
Locale: de-DE (de_DE.UTF-8); UI: en-US
Calc: threaded

Couldn't reproduce with this version.
French date works as expected.
Comment 2 Justin Scott 2024-07-30 02:47:29 UTC
I have had similar issues with the User Field feature as well.  It is certainly not reliable.  I am a landlord and I tried using these to make up my leases.  I wanted to have a User Field for the rent, security deposit, keys furnished, etc.  If the User Field feature worked I could update these values in one interface and not have to crawl through the entire lease to update each of these things every time they show up in the document.  But when I try changing the user fields (I try doing this through Insert -> Field -> More Fields -> Variables interface) more often than not the value does not update.

I don't have time tonight but I will post another comment with steps to reproduce.  This feature would be really useful for someone like me and it is quite frustrating that it is too unreliable to use.
Comment 3 Buovjaga 2024-08-30 06:32:40 UTC
I noticed that we can't test this on 24.8 due to bug 162702. I also noticed additional KDE-only issues bug 162703 and bug 162704.
Comment 4 Buovjaga 2024-11-19 10:18:22 UTC
(In reply to Colin Pitrat from comment #0)
> Now double click on the field. You can edit it. Try setting it to
> "10/07/2023". The value actually taken is "07/10/2023". This has the funny
> side-effect that clicking on Apply multiple times keeps changing the date
> between July 10th and October 7th.

When I click the apply button, the value changes to 30/12/1899 00:01:01

I guess the badness is close enough that this can be set to NEW.

Arch Linux 64-bit
Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: c8b607b7c0096c58dc5187262bf0133dee728d50
CPU threads: 8; OS: Linux 6.11; UI render: default; VCL: kf6 (cairo+wayland)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: CL threaded
Built on 19 November 2024
Comment 5 Buovjaga 2024-11-19 13:56:57 UTC
This whole use case is only now becoming usable. The field value display was broken for years, showing as 30/12/99 until version 7.6 and commit 8c8457526a11fd03ed63a86ecdeeb270d5551049 (also backported to 7.5.3).