> On Nov 6, 2018, at 4:08 AM, Jörg Schaible <[email protected]> wrote: > > Hi David, > > On Mon, 05 Nov 2018 02:30:39 +0000 David T. via gnucash-user wrote: > >> Jörg, >> Frank points you to the spurious date that is likely the source of your >> trouble. > > I guessed also. > >> I believe that at some point, the developers put in a data >> check into the upgrade process, to prevent errors from propagating >> forward, which would explain the problem arising now. > > That check seems not in place when a file from an older version is silently > converted and when the file is > written ... :-/ > >> Perhaps you could >> manually add a '3' after '201' before reopening the file. > > I already tried this (but with 2018) and gnucash 3.3 still failed to open the > file. But that was before I compared > the old and new file and recognized that the new version also removes the > date-posted element (at least > when the value seems to correlate with 0). > > ... > > > But you were right. After correcting the gdate to 2013-01-02 and adding a > matching date-posted element, I > could read the file with the latest version 3.3.
It’s failing to load because of the deleted date-posted element. It shouldn’t be deleted, 0 is now a perfectly valid date since 2.6.0. Slots aren’t evaluated at load time so that was just a distraction. Can you file a bug about the XML backend eating 0 date-posted values? Regards, John Ralls _______________________________________________ gnucash-user mailing list [email protected] To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
