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
repro with 7.4.0.0+
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
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).
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"
The display format comes out like "8. Apr 22"
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.
Writerfilter is just applying the given date with the user-defined specified format. <w:instrText>DATE \@"d'. 'MMM\ yy"</w:instrText>
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.
(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.
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.
(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.
Pending review https://gerrit.libreoffice.org/c/core/+/132703 for 7-3
(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.
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.
(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> ;-)
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
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.
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.