GNOME Bugzilla – Bug 795377
Reads and saves Gnucash 2.6.19 XML file, then can't reread it, due to bad date in old file
Last modified: 2018-06-30 00:08:35 UTC
I compiled GnuCash 3.0 from source and ran it. Previously I had used GnuCash 2.6.19. GnuCash successfully read in the XML file that had previously been saved by 2.6.19. Then I saved, exited, and relaunched GnuCash 3.0. While launching, it printed a random <gnc:transaction> XML blob to the console, and then when it finished reading in the XML file it reported: `There was an error parsing the file [filename].` I diff'd a copy I had made of the 2.6.19 file with the one that was saved by GnuCash 3.0, and I observed this difference among others: @@ -199698,12 +199698,9 @@ <gnc:transaction version="2.0.0"> <trn:id type="guid">98688369b279955c65cc7e973549c41b</trn:id> <trn:currency> - <cmdty:space>ISO4217</cmdty:space> + <cmdty:space>CURRENCY</cmdty:space> <cmdty:id>USD</cmdty:id> </trn:currency> - <trn:date-posted> - <ts:date>1020-11-02 06:02:58 -0456</ts:date> - </trn:date-posted> <trn:date-entered> <ts:date>2016-11-02 09:59:55 -0400</ts:date> </trn:date-entered> I edited the old file by hand to fix the bad date shown above as well as a `<gdate>1020-11-02</gdate>` in a slot on the same transaction, and then repeated the experiment. This time GnuCash 3.0 was able to read and save the old file and then read it again when I relaunched it. So it would seem that GnuCash 3.0 is silently discarding the bad date on the transaction, and then saving the transaction without the required <trn:date-posted> element, and then refusing to reread the file because of the missing <trn:date-posted>.
*** Bug 795532 has been marked as a duplicate of this bug. ***
Gnucash 3.0 as released did indeed have trouble with invalid dates in the data file. And what constitutes an invalid date has slightly changed as well. 2.6.x would accept anything more recent than the year 1000. As we changed the date system to be based on boost::date this limit as now been raised to 1400. Which explains why the date in your snippet above does work on 2.6 and not on 3.0. I thought John had at least included a fix for 3.1 that would catch invalid dates and replace them with 1970-01-01. That would prevent gnucash from discarding it. I'm not sure why he kept this bug open though. Can you rerun your test on a build from the current maint and report back how that goes ?
This bug is after the bad date crash was fixed. It seems that GnuCash isn't recognizing the bad date as a valid date--it's probably some filter in the XML backend that thinks "0" is an invalid time64--and not writing out the date element. The XML parser when loading the file aborts when the essential element is missing and reports the file isn't readable.
I have committed a number of changes to the xml parser that should deal with this. When a bad date is encountered a warning will be written to the trace file. If that date is visible in the gui, it will be replaced with 1-1-1970. If you subsequently make any change to the book and save it this 1-1-1970 will be saved into your book. The <gdate> entry on the other hand will continue to trigger writing a warning message to the trace file each time you open the book until you explicitly change the corresponding 1-1-1970 transaction date and save the book. I read you fixed it for yourself by manually correcting the dates. However could you retry the experiment with an older file (load, make change, save, reload) to verify my fix is working ?
I am able to read, safe, and re-read an old gnucash file with the errant 1020 date in it with current trunk.
Great! So this bug can be closed.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=795377. Please update any external references or bookmarks.