Bug 90658 - FILEOPEN Date field in Word 6.0 document have wrong formatting
Summary: FILEOPEN Date field in Word 6.0 document have wrong formatting
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Fields-Variable
  Show dependency treegraph
 
Reported: 2015-04-16 17:06 UTC by Karl Ove Hufthammer
Modified: 2025-08-05 03:10 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample document, which is rendered incorrectly in LibreOffice (10.50 KB, application/msword)
2015-04-16 17:06 UTC, Karl Ove Hufthammer
Details
Screenshot of document in Word 6.0 (2.61 KB, image/png)
2015-04-16 17:09 UTC, Karl Ove Hufthammer
Details
Screenshot of document in LibreOffice (9.09 KB, image/png)
2015-04-16 17:10 UTC, Karl Ove Hufthammer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Karl Ove Hufthammer 2015-04-16 17:06:47 UTC
Created attachment 114832 [details]
Sample document, which is rendered incorrectly in LibreOffice

See the attached Word 6.0 document. On the top-right corner of the page, the date should be displayed as ‘28.01.1998’. Instead, it’s displayed as ‘28.1.1998’ (note the missing leading zero in the month).
Comment 1 Karl Ove Hufthammer 2015-04-16 17:09:17 UTC
Created attachment 114833 [details]
Screenshot of document in Word 6.0
Comment 2 Karl Ove Hufthammer 2015-04-16 17:10:22 UTC
Created attachment 114834 [details]
Screenshot of document in LibreOffice

(Note that there are also other bugs in the rendering, but I’ll file separate bug reports for them.)
Comment 3 Buovjaga 2015-04-18 11:09:08 UTC
Confirmed.

Ubuntu 14.10 64-bit
LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4

Win 7 Pro 64-bit, Version: 4.4.2.2
Build ID: c4c7d32d0d49397cad38d62472b0bc8acff48dd6
Locale: fi_FI

Version: 5.0.0.0.alpha0+ (x64)
Build ID: 211c12b9c64facd1c12f637a5229bd6a6feb032a
TinderBox: Win-x86_64@42, Branch:master, Time: 2015-04-18_01:51:17
Locale: fi_FI
Comment 4 Xisco Faulí 2016-04-21 16:06:23 UTC
Still reproducible in

Version: 5.2.0.0.alpha0+
Build ID: 3dca8575d63db50b0120fbff09bbfcd056fa3732
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2016-04-20_05:07:29
Locale: es-ES (es_ES)
Comment 5 QA Administrators 2017-05-22 13:24:48 UTC Comment hidden (obsolete)
Comment 6 Karl Ove Hufthammer 2017-05-22 18:58:26 UTC
I can confirm that this bug is still present in

Version: 5.3.3.2
Build ID: 30m0(Build:2)
CPU Threads: 4; OS Version: Linux 4.10; UI Render: default; VCL: gtk3; Layout Engine: new; 
Locale: en-US (C); Calc: group
Comment 7 QA Administrators 2018-05-23 02:35:48 UTC Comment hidden (obsolete)
Comment 8 Karl Ove Hufthammer 2018-05-23 19:17:56 UTC
I can confirm that this bug is still valid in:

Versjon: 6.0.4.2
Build ID: 00m0(Build:2)
CPU-trådar:4; OS:Linux 4.16; UI-utformar:standard; VCL: gtk3; 
Lokale: nn-NO (nn_NO.UTF-8); Calc: CL
Comment 9 QA Administrators 2019-05-24 02:57:31 UTC Comment hidden (obsolete)
Comment 10 sdc.blanco 2020-01-03 03:26:04 UTC
1.  Open Sample Document
2.  Look at Properties  ( File > Properties )
3.  Notice that Title is:  28.1.1998
4.  Change to:  28.01.1998
5.  Save/Reload 

Result:  Success

Tested with: 
Version: 6.5.0.0.alpha0+ (x64)
Build ID: 444f0d256957544d26b9af9a0898364e829df1b5
CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: GL; VCL: win; 
Locale: sv-SE (en_DK); UI-Language: en-US
Calc: threaded

I do not have a copy of Word to test the original document, but 
if the title was also 28.1.1998 in Word -- then I would be inclined to say: NAB
Comment 11 Karl Ove Hufthammer 2020-01-05 11:22:04 UTC
> I do not have a copy of Word to test the original document, but 
> if the title was also 28.1.1998 in Word -- then I would be inclined to say:
> NAB

The *literal* title is ‘28.1.1998’. But the fact that the date formatting isn’t applied to the merge field is what this bug is all about. The ‘merge field’ has a date format option applied, which specifies that it should be formatted as ‘\@ "dd.MM.yyyy"’ (i.e., with a leading zero for the month part). But this isn’t taken into account when LibreOffice imports the document.

In Word 6, in which the document was created, the title is is displayed as ‘28.01.1998’. And I just tested this in Word 2016, and it’s displayed as ‘28.01.1998’ there too.
Comment 12 sdc.blanco 2020-01-05 12:28:01 UTC
(In reply to Karl Ove Hufthammer from comment #11)
> 
> In Word 6, in which the document was created, the title is is displayed as
> ‘28.01.1998’. And I just tested this in Word 2016, and it’s displayed as
> ‘28.01.1998’ there too.

Ok.  I did not see any mention of "merge field" in the original report.

Just to clarify the situation:

Double-click on the field in question (to get the "edit field" dialog). LO is presenting a "title" (from Document properties) with no formatting.  

In effect, you are expecting or requesting that date-like strings in the title field (in Document Properties) should be interpreted as a date.

Meanwhile, insert a "Created" field (Ctrl-F2, DocInformation tab, Created), then 27.01.1998 is shown (double-click on that field, to see possibilities to format how the date appears).

I will leave it to more knowledgeable persons to decide how to classify the situation.  At best, it seems more like a doc:filter question, in terms of how Word document properties are expressed in LO capabilities.
Comment 13 QA Administrators 2022-01-05 03:39:34 UTC Comment hidden (obsolete)
Comment 14 Karl Ove Hufthammer 2023-08-05 09:12:10 UTC
I can confirm that this bug is still present in:

Version: 7.5.4.2 (X86_64) / LibreOffice Community
Build ID: 50(Build:2)
CPU threads: 4; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb)
Locale: nn-NO (nn_NO.utf8); UI: nn-NO
Calc: threaded
Comment 15 QA Administrators 2025-08-05 03:10:34 UTC
Dear Karl Ove Hufthammer,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug