User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0 Build Identifier: LibreOffice 5.1.3.2 Running in Windows 10 64 bit I insert a date using the fixed date field using the full day, month, date, year it inserts the date, but when I open the document a week later it shows that date rather then the original date. ie: Date when inserted - Sunday, July 3, 2016. Date when opened one week later - Sunday, July 10, 2016 This document is saved twice in .DOC and .ODT formats. It happens in both documents. Reproducible: Always Steps to Reproduce: 1.<Insert> 2.<Field> 3.<More Fields> 4.Document Tab, Type=Date, Select=Date (Fixed) Format=Friday, December 31, 1999, Offset in Days=0 Actual Results: The date of the current date is inserted in this case Sunday, July, 3, 2016. Expected Results: It should have remained Sunday, July 3, 2016, when I opened the document a week (7 days) later. Instead the date read Sunday, July 10, 2016. [Information automatically included from LibreOffice] Locale: en-US Module: TextDocument [Information guessed from browser] OS: Windows (All) OS is 64bit: yes Reset User Profile?No
It inserts a dynamic date instead of a fixed date
Unconfirmed with v5.1.5.1 under windows 7 x64. Fixed date stays fixed. Maybe you wanna try a newer version and let us know if it's fixed or not....
I can't reproduce it, either (LibreOffice 5.1.4.2 / Windows 7), I tested with changing the system date manually. Could you upload a minimal example with a fixed date? Then we could easily see days later what happens with the date field.
Someone just commented this in a different bug: https://bugs.documentfoundation.org/show_bug.cgi?id=63535#c7 It seems the fixed date becomes just date when saved in DOC, then if saved back to ODT, it won't be fixed. I can confirm this part of the bug. However if you keep ODT format, the date remains fixed for me. What was the process you saved to DOC and ODT?
Some additional experience with DOCX format: "I tried again with two new documents in .docx (WW 2017-2013 and Open XML). It is was almost good, but French date month is converted to English : "21 juillet 2016" come back to "21 July 2016" in "Date (fixed)"." https://bugs.documentfoundation.org/show_bug.cgi?id=63535#c11
This is a weekly report kept for a year. It has been around for years. Every year I delete all but one page, delete the weekly data, leave the headings and insert the new date. It is then saved in both the .DOC and .ODT format (I got zapped by ransomware so I use .DOC for aharing and .ODT in hopes that if it happens again it won't zap that). I will create two new documents one .Doc one .ODT wait a day or two see what happens and then cross save to see what happens. I'll report back next week.
Setting to NEW, as the issue has been reproduced. So there are two, closely related issues: -fixed date is not fixed anymore when exported to DOC, -fixed date can come back in different language when exported to DOCX.
(In reply to Aron Budea from comment #7) > Setting to NEW, as the issue has been reproduced. > So there are two, closely related issues: > -fixed date is not fixed anymore when exported to DOC, > -fixed date can come back in different language when exported to DOCX. Confirming with: Version: 5.3.0.0.beta1 Build ID: 690f553ecb3efd19143acbf01f3af4e289e94536 CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Layout Engine: new; Locale: nl-NL (nl_NL); Calc: C
*** Bug 107533 has been marked as a duplicate of this bug. ***
About fixed date is not fixed anymore when exported to DOC Repro with Version: 5.5.0.0.alpha0+ Build ID: 076ed447f694239d5c67adee528ea6e471d909ff CPU threads: 4; OS: Windows 6.19; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-06-09_23:54:20 Locale: en-US (nl_NL); Calc: CL and with Version: 5.0.2.2 Build ID: 37b43f919e4de5eeaca9b9755ed688758a8251fe-GL Locale: en-US (nl_NL) but not with Versie: 4.4.6.3 Build ID: e8938fd3328e95dcf59dd64e7facd2c7d67c704d Locale: nl_NL
(In reply to Telesto from comment #10) > but not with > Versie: 4.4.6.3 > Build ID: e8938fd3328e95dcf59dd64e7facd2c7d67c704d > Locale: nl_NL With 4.4.7 and 4.3.0, the field turns into regular text when exporting to DOC, so I would not call this a regression. Am I missing something? Can someone share a DOC created with pre-5.0 that shows a working fixed date field?
I checked what's possible in Word, and it appears Word inserts fixed dates as a piece of text, and nothing else. Perhaps it's just an unsupported type in DOC formats. However, in that case possibly the old behavior was the correct one, which turned fixed dates into a piece of text - the fieldness is removed, but the date remains fixed.
(In reply to Aron Budea from comment #12) > I checked what's possible in Word, and it appears Word inserts fixed dates > as a piece of text, and nothing else. Perhaps it's just an unsupported type > in DOC formats. However, in that case possibly the old behavior was the > correct one, which turned fixed dates into a piece of text - the fieldness > is removed, but the date remains fixed. Saving a test document to DOCX results in correct roundtrip (wrt this specific issue that is about const-ness of fields); Word also opens the generated DOCX with fields in it, having const values. Then, you can save the DOCX to DOC using Word, and get a DOC with const fields - so the DOC format supports the const date/time fields. But opening the resulting DOC (generated by Word) using LO gives non-const date/time fields - so it's at least import filter issue.
Created attachment 148057 [details] A DOC with const date and time fields saved with Word 2003
(In reply to Mike Kaganski from comment #14) > Created attachment 148057 [details] > A DOC with const date and time fields saved with Word 2003 Removing regression-related keywords as file opening behaviour is the same in older versions (oldest of 44max and 43all repos). It is opened with non-const date and time, showing the current date and time instead.
Here is the relevant part from mso-dumper, the key here being grffldEnd bit E_Locked <fld type="FLD" offset="1366" size="2 bytes"> <fldch type="fldch" offset="1366" size="1 byte"> <ch value="0x13"/> #tyep of field <reserved value="0x0"/> </fldch> <grffld value="0x1f"/> #a Date field. </fld> </aCP> <aCP index="1" value="18"> <fld type="FLD" offset="1368" size="2 bytes"> <fldch type="fldch" offset="1368" size="1 byte"> <ch value="0x14"/> #unused/ignored <reserved value="0x4"/> </fldch> <grffld value="0xff"/> #ignored </fld> <transformed value="DATE \@"dd.MM.yy""/> </aCP> <aCP index="2" value="27"> <fld type="FLD" offset="1370" size="2 bytes"> <fldch type="fldch" offset="1370" size="1 byte"> <ch value="0x15"/> #grffldEnd <reserved value="0x4"/> </fldch> <grffld value="0x90"/> #10010000 E_Locked = this field does not recalculate, H_fHasSep = set if this field has a separator. </fld> <transformed value="05.01.19"/>
That grffldEnd is loaded into WW8FieldDesc.nOpt. So I think we want to set our date and time fields to DATE_FIX enum SwDateSubFormat { DATE_FIX, #never used. Gets converted to FIXEDFLD(aka 1 - so confusing) DATE_VAR #this is the one to search for. }; as well as setting the field's time to what was stored in the file.
OK - there are a lot of different parts to this bug. Things act differently depending on if the field was inserted via the UI/ODT, or imported from .doc. Confirmed that the .doc imported date field round-trips always as a variable field (since at least 3.5). [Ahh - of course, because the imported field is variable, and the ODT one is fixed. Duh. Confirmed that if you CHANGE the .doc imported time to FIXED, then 3.5-4.4 export as plain text.] In 5.0 DOC/RTF start exporting as a field with bug 59886's commit a072b3533f44730565f42b45cfd9f77f44f506a9 Author: Eilidh McAdam on Dec 19 16:56:58 2014 +0000 fdo#59886 export fixed date and time fields to docx. Fixed date and time fields are supported in OOXML by adding the attribute fldLock="true" to the fldChar element. This applies only to the first instance of fldChar in a field (i.e. when fldCharType is "begin"). -------------------------------------------------------------------------------- Import WIP started at https://gerrit.libreoffice.org/c/core/+/113986. BTW, what GOOD is a const date field? Why shouldn't it just be turned into plain text on import? + if (pF->nOpt & 0x10) // E_locked field option - do not recalculate + return eF_ResT::TEXT;
(In reply to Justin L from comment #18) > BTW, what GOOD is a const date field? Why shouldn't it just be turned into > plain text on import? It is absolutely necessary for *templates*, where it is calculated once upon creation of a new document from such template. Being a *field*, it also allows to adjust to locale dynamically (modifying display string as reader expects), if its locale is not fixed.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/dafdcb748a54a5e41bcb61f67355e06265bf98ff tdf#100961 doc/rtf export: save FIXEDFLD as fldlock It will be available in 7.2.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4ed7a2c8af03bc0f45df1f03fd160ccbf045ed4f tdf#100961 rtf import: fldlock is FIXEDFLD It will be available in 7.2.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.
I'm not going to do the last step of importing into DOC. a.) It seems to require UNO garbage, and I can't stand working with that junk unless I can just copy/paste - which I have no examples to find here. b.) All the plumbing for turning a date-or-time-string into a DateTime is mostly missing. Sure, there is convertStringToNumber from https://cgit.freedesktop.org/libreoffice/core/commit/?id=8826934016d60d0a4a1e824e3f1cff814d915515, but that is unfathomable UNO junk that returns only a float (why not return as DateTime?) - and none of the date/time methods accept the float as an initializer, so more plumbing is needed. Plus, none of that actually accepts the format string that we already know from the field itself, which specifies %YY.mm.dd, etc. c.) I really don't want to write my own function to parse date/time based on the field strings.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/74a8bda42d443c8fbcfab7619a929ccf53a00918 partial fix tdf100961 doc import: E_Locked field as plain text It will be available in 7.2.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.
*** Bug 143057 has been marked as a duplicate of this bug. ***
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/79d31d08146afa0861ceb1705262411449e71ec7 tdf100961: import fixed date/time field attribute from DOC It will be available in 7.3.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.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/0381a6f556ab973d847a6f2b1d4fa83f9d6cc833 tdf100961: import fixed date/time field attribute from DOC It will be available in 7.2.0.0.beta2. 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.
I exported to .doc . In 7.1.4 the date is dynamic. In 7.2 is ok, it's fixed. Verified with Version: 7.2.0.1.0+ (x64) / LibreOffice Community Build ID: ffeeb78118a887419c5f33bb5311f0e2ddae463c CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: ro-RO (ro_RO); UI: en-US Calc: threaded Thanks for fixing this.
For me still REPRODUCIBLE with very old document templates and Installation of Version: 7.5.0.1 (X86_64) Build ID: 77cd3d7ad4445740a0c6cf977992dafd8ebad8df CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: default; VCL: win – Locale: de-DE (de_DE); UI: de-DE Calc: threaded | Elementary (SVG) Theme | Normal UserProfile (With this version the date field has become edited last time. Is the problem related to the LibO version with which the document * became created? * became edited last time? * became opened now and now shows the problem?
(In reply to Rainer Bielefeld Retired from comment #28) Needs an own bug report, with the problematic document.