Description: I specify a Date/Time format in a document ("YYMMDD.HHMM") as a timestamp, and it displays correctly, but when I close the document and reopen it, that format is not preserved. It is displayed as "MM/DD/YYYY.HH:MM:SS" and I have to manually change it again each time. Steps to Reproduce: Insert Date field in footer with custom format: YYMMDD Observe that it displays correctly, for example: 200517 Close the document and reopen. Now it displays: 5/17/20 Actual Results: 5/17/20 Expected Results: 200517 Reproducible: Always User Profile Reset: No Additional Info: Version: 6.4.3.2 Build ID: 1:6.4.3-0ubuntu0.20.04.1 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded
Created attachment 160946 [details] WORKING Please try to change to date on that format like in my video. Waiting for your results.
Created attachment 160949 [details] Video showing this reproducible bug.
This video shows creation of a new Writer document using my default template, which has my standard "yymmdd.hhmm" timestamp in the footer...
Thanks for the video. Confirm it on Version: 7.0.0.0.alpha1 Build ID: 6a03b2a54143a9bc0c6d4c7f1... CPU threads: 4; OS: Linux 5.4; UI render: Skia/Raster; VCL: gtk3; Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded It is taking system date and time, and not the customized date and time.
Yes, I tried it on 7.0alpha, and it did the same.
Confirmed issue exists. Version: 6.4.3.2 Build ID: 1:6.4.3-0ubuntu0.20.04.1 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.UTF-8); UI-Language: en-US Calc: threaded
This problem does NOT appear in version 7.0Beta2, however, I cannot depend on that version because of other bugs in it.
Likely a duplicate of Bug 133459. If 7.0Beta2 doesn't work for you, you can also try a dev snapshot of the 6.4 branch (what will eventually released as 6.4.6): https://dev-builds.libreoffice.org/daily/libreoffice-6-4/ *** This bug has been marked as a duplicate of bug 133459 ***
David, the bug you reported will be solved in 6.4.6 which will be release around this date: Jul 26, 2020
(In reply to BogdanB from comment #9) > David, the bug you reported will be solved in 6.4.6 which will be release > around this date: Jul 26, 2020 Thank you!