Bug 148052 - FILEOPEN DOCX: Date(fixed) or Time(fixed) fields with has a '.' in the Date Format are updated dynamically in Writer
Summary: FILEOPEN DOCX: Date(fixed) or Time(fixed) fields with has a '.' in the Date F...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.1.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Eike Rathke
URL:
Whiteboard: target:7.4.0 target:7.3.3 target:7.2.7
Keywords: bibisected, bisected, filter:docx, regression
Depends on:
Blocks: DOCX-Fields
  Show dependency treegraph
 
Reported: 2022-03-17 11:48 UTC by sdc.blanco
Modified: 2022-04-13 12:40 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
test file to demonstrate problem (17.44 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2022-03-17 11:48 UTC, sdc.blanco
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sdc.blanco 2022-03-17 11:48:52 UTC
Created attachment 178941 [details]
test file to demonstrate problem

Attached file is created (by Writer) with a Date(fixed) field in the footer.

1.  Open the file using Word.
        Result (and expected):  Fixed date is shown.
2.  Open the file using Writer.
        Result:  Date field shows current date.
        Expected:  Date field shows original fixed date.


Additional information
1. Editing the field in Writer shows that it is registered as a Date(fixed) field.
2. Attached file is not a special case. I have many actual files with same problem.
3. My memory is that this probably started about 3-4 years ago.  That is, possible regression.
4. Have not checked .doc
Comment 1 sdc.blanco 2022-03-17 11:50:35 UTC
repro with 7.4.0.0+
Comment 2 Dieter 2022-03-31 15:14:26 UTC
I confirm it with

Version: 7.3.2.2 (x64) / LibreOffice Community
Build ID: 49f2b1bff42cfccbd8f788c8dc32c1c309559be0
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: zh-CN (de_DE); UI: en-GB
Calc: CL
Comment 3 Justin L 2022-04-08 05:56:34 UTC
Bibisect-linux-64-7-1 points to
commit 7186541219599e1b51ad35601c2cd015a329f360
Author: Eike Rathke on Fri Jul 3 19:09:33 2020 +0200
    Resolves: tdf#131562 decimal separator may not be surrounded by blanks
    
    1 .
    1 .2
    1 . 2
    1. 2
     . 2
    . 2
    are not numbers. But
     .2
    is.


I tried testing DOC/RTF formats using this document, but they just export as non-fixed (tested in LO 5.1/7.0).
Comment 4 Justin L 2022-04-08 06:16:13 UTC
CC: Eike

SetNumberFormat[d'. 'MMM\ yy] from command[DATE \@"d'. 'MMM\ yy"] sConverted[d". "MMM\ yy]
svl/source/numbers/zforfind.cxx:515: ::SkipBlanks[. AUG ] start[0] < nPos[0]
svl/source/numbers/zforfind.cxx:515: ::SkipBlanks[. AUG ] start[1] < nPos[2]
svl/source/numbers/zforfind.cxx:515: ::SkipBlanks[. AUG ] start[0] < nPos[0]
writerfilter/source/dmapper/DomainMapper_Impl.cxx:7182: DomainMapper_Impl::SetFieldResult com.sun.star.util.NotNumericException message: "at /persistent/git/libreoffice2/svl/source/numbers/numfmuno.cxx:170"
Comment 5 Justin L 2022-04-08 06:37:07 UTC
The display format comes out like "8. Apr 22"
Comment 6 Eike Rathke 2022-04-08 16:40:59 UTC
It's tried to parse "14. Aug 18" in en-US, that's not a valid en-US medium date format hence not a numeric value. Whyever writerfilter then assumes it would be the current date I didn't investigate, maybe because it needs *some* valid numeric date as the display string is not the actual field data.

However, given that the `D. MMM YY` date format is known as well, we could tweak the logic to parse that piece according to the known number format (or even generally try a month name if something like that follows, ignoring the locale specific restriction?) if it otherwise failed.

I'll try to take a stab at this.
Comment 7 Justin L 2022-04-08 18:01:34 UTC
Writerfilter is just applying the given date with the user-defined specified format.

<w:instrText>DATE \@"d'. 'MMM\ yy"</w:instrText>
Comment 8 Eike Rathke 2022-04-08 21:03:14 UTC
But there is no given date that could be formatted, there's only the display text
<w:t>14. Aug 18</w:t>
that is tried to parse as date first.

Happens in writerfilter/source/dmapper/DomainMapper_Impl.cxx DomainMapper_Impl::SetFieldResult() with rResult="14. Aug 18" line 7021

uno::makeAny( lcl_dateTimeFromSerial( xFormatter->convertStringToNumber( nKey, rResult ) ) ) );   │

where already convertStringToNumber() throws util::NotNumericException, hence the Any is not set as DateTimeValue property.

If that is supposed to be the creation date then that date should be used as obtained from docProps/core.xml
<dcterms:created xsi:type="dcterms:W3CDTF">2018-08-14T15:12:00Z</dcterms:created>

The XML parser context domain mapper apparently has no information of what that field date actually is. Unless it's hidden in the IDs of the containing paragraph
<w:p w14:paraId="2C0FD485" w14:textId="77777777" w:rsidR="00B64271" w:rsidRDefault="003B5D6A">
or some magic "it's in the footer with w:fldLock="1" so it must be the fixed creation date". Maybe Word also always parses it against the format, who knows.
Comment 9 sdc.blanco 2022-04-08 22:01:39 UTC
(In reply to Eike Rathke from comment #6)
Meanwhile, I have noticed that I have the same problem with a file (created in 2019 by Writer and saved as .docx) that uses TIME(fixed) fields and 'D. MMM YYYY' date format.  

All the Time(Fixed) fields now appear with the current date in Writer 7.4.0.0 (while Word displays those fields with the last-modified date of the file). (i.e., file probably saved with LO 7.2.5)

(Checking a backup of that file from Jan 21, probably saved with LO 7.0.{3|4} Word now displays the Time(fixed) field correctly, while Writer 7.4.0.0 still shows current date).

(Should I file a separate ticket for the fact that LO seems to save the current date in a fixed Time field with a . in the date format?)  

As I understand, the problem may be because of the . in the date format. That is consistent with this file, which also had some Date(Fixed) fields, all of which appeared correctly even though saved with LO 7.2.5, because none of those Date(fixed) fields had a . in the date format. 

Finally, fwiw I have used Time/Date(fixed) fields (with a . in the date format) for years without any problems. It is only in recent years that these difficulties have arisen. Thanks for taking a look at it.
Comment 10 Commit Notification 2022-04-09 00:24:22 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/7a16002ede5fd31ae8f3358136ad49de40465ac1

Resolves: tdf#148052 accept a ". Month " name for matching DMY format

It will be available in 7.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 11 Eike Rathke 2022-04-09 00:25:53 UTC
(In reply to sdc.blanco from comment #9)
> (Should I file a separate ticket for the fact that LO seems to save the
> current date in a fixed Time field with a . in the date format?)  
No, that appears to be the very same thing.
Comment 12 Eike Rathke 2022-04-09 00:26:49 UTC
Pending review https://gerrit.libreoffice.org/c/core/+/132703 for 7-3
Comment 13 Justin L 2022-04-09 12:32:37 UTC
(In reply to Eike Rathke from comment #8)
> But there is no given date that could be formatted, there's only the display
> text
> <w:t>14. Aug 18</w:t>
Yup. I think the only purpose here is to provide the formatting so that the displayed text can be turned back into a date-number since the format string is given.

> If that is supposed to be the creation date 
Nope - just a unchangeable date in a field.

> The XML parser context domain mapper apparently has no information of what
> that field date actually is. 
17.16.5.13 DATE
Description: The current date and time.

> w:fldLock="1" Maybe Word also always parses it against the format, who knows.
Exactly. With it being locked (or fixed in LO parlance) you can easily parse the date no matter what kind of funky user-defined format is used to specify the date.
Comment 14 Commit Notification 2022-04-09 20:19:30 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-7-3":

https://git.libreoffice.org/core/commit/29f7b81afcf2e21c88c38fbae31fb463b26040c1

Resolves: tdf#148052 accept a ". Month " name for matching DMY format

It will be available in 7.3.3.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 15 Eike Rathke 2022-04-09 22:08:54 UTC
(In reply to Justin L from comment #13)
> > The XML parser context domain mapper apparently has no information of what
> > that field date actually is. 
> 17.16.5.13 DATE
> Description: The current date and time.
Huh? That wouldn't make sense here.

> > w:fldLock="1" Maybe Word also always parses it against the format, who knows.
> Exactly. With it being locked (or fixed in LO parlance) you can easily parse
> the date no matter what kind of funky user-defined format is used to specify
> the date.

Please try that in Word with the footer modified to
<w:instrText>DATE \@"yy-dd'. 'MMM"</w:instrText>
<w:t>18-14. Aug</w:t>

;-)
Comment 16 sdc.blanco 2022-04-10 14:20:45 UTC
Verified with:

Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: d34d1db55978bdcff082af1e0f75b18fa6fc94f4
CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: da-DK (da_DK); UI: en-US
Calc: CL

Many thanks! -- can "read" fixed dates properly in old files again.  Also, from light testing, it seems that when fixed fields are saved as .docx (using the patched version), then they are read properly with the fixed value (if viewed with the patched version).

But one question, if I may. Is the (basic) idea -- as long as the date/time format is accepted by the Edit Fields - Additional formats dialog -- then the fixed field should work as expected (i.e., fixed value is preserved and if viewed with the patched (or pre-June 2020) version of LO, then the preserved value is displayed correctly). 

(I tried with some (pathological?) examples (e.g., D. MMM. YYYY) and it seemed work as expected -- where I moved system time forward, to see if the fixed date is preserved).

-- just trying to avoid this problem in the future.  Also, do not know if anything should be added to the documentation in this connection. Maybe here in the Date and Time formats section. 

https://help.libreoffice.org/7.4/en-US/text/shared/01/05020301.html
Comment 17 Commit Notification 2022-04-11 13:37:20 UTC
Xisco Fauli committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/bc227a15db04e218f34c6e2055c05b3cee67e4cf

tdf#148052: sw_ooxmlexport17: add unittest

It will be available in 7.4.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 18 Commit Notification 2022-04-13 12:40:25 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-7-2":

https://git.libreoffice.org/core/commit/91d9204d8eb1fd6b923d5af618f66acdbdf0d75d

Resolves: tdf#148052 accept a ". Month " name for matching DMY format

It will be available in 7.2.7.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.