After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 543212 - SX is setting date for postponed TX incorrectly
SX is setting date for postponed TX incorrectly
Status: RESOLVED DUPLICATE of bug 672760
Product: GnuCash
Classification: Other
Component: Scheduled Transactions
2.4.x
Other All
: Normal normal
: ---
Assigned To: Josh Sled
Josh Sled
Depends on:
Blocks:
 
 
Reported: 2008-07-16 03:14 UTC by Volker Englisch
Modified: 2018-06-29 22:07 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
diff showing the changed state after postponing several SXes (10.08 KB, text/plain)
2012-03-16 20:56 UTC, Gour
Details

Description Volker Englisch 2008-07-16 03:14:13 UTC
Please describe the problem:
I am using scheduled transactions heavily.  For a while now I have noticed that occasionally a date for a transaction displayed in the 'Since last run' window is incorrect.  Sometimes a TX reoccurring weekly is off by a year or two and sometimes the date is completely off the chart like this:  48419-04-04

I had reported this a while back on the GnuCash list but couldn't offer much help on how to track this down.  Please see
   https://lists.gnucash.org/pipermail/gnucash-devel/2008-March/022779.html
as a reference including a screen shot.

Steps to reproduce:
I was able to reproduce the problem as follows:
1. After every GnuCash session I am checking for the largest date stored in the <gdate> element (knowing that the largest date should be 2032-01-01.
I used a grep for this
  grep "<gdate>" filename | sed 's/ *\(<gdate>\)\(.*\)\(<\/gdate>\)/\2/' | sort -u | tail -1

2. I am running 'Since last run' (automatically at the start of GC)
3. There are several TX with a status of 'To Create' which
   I change to the status of 'Postponed'
4. Click 'OK' to apply the TXs
5. The next time I run 'Since last run' those TXs I set to postpone are 
   displayed with an incorrect, different date.


Actual results:
Often, the dates of the transactions are changed even though the dates shouldn't change at all between runs of the 'Since Last Run'.  However, this does not appear to happen *every* time a transaction is postponed (or maybe it is but I haven't noticed so far).  I don't think, though that setting a transaction to the status of 'Remind' has the same effect.

Expected results:
The date should not change when the status for a transactions is set to 'Postponed'.

Does this happen every time?
I don't think it does.  I've been trying to track down this problem for the past two weeks (but it's been there for a while longer).  Now that I know what triggers it I'll be able to pay closer attention.

Other information:
As usual, if you need additional information please let me know.
Comment 1 Volker Englisch 2008-07-16 04:21:27 UTC
Here is the complete content of one such mangled scheduled TX:
<gnc:schedxaction version="2.0.0">
  <sx:id type="guid">f3276789ef9b3fabb2c59d8d2946a977</sx:id>
  <sx:name>BG&amp;E kWh</sx:name>
  <sx:enabled>y</sx:enabled>
  <sx:autoCreate>n</sx:autoCreate>
  <sx:autoCreateNotify>n</sx:autoCreateNotify>
  <sx:advanceCreateDays>0</sx:advanceCreateDays>
  <sx:advanceRemindDays>14</sx:advanceRemindDays>
  <sx:instanceCount>143246888</sx:instanceCount>
  <sx:start>
    <gdate>2007-07-16</gdate>
  </sx:start>
  <sx:last>
    <gdate>2008-07-15</gdate>
  </sx:last>
  <sx:templ-acct type="guid">62473185952e4bb534d5288dab874de7</sx:templ-acct>
  <sx:schedule>
    <gnc:recurrence version="1.0.0">
      <recurrence:mult>1</recurrence:mult>
      <recurrence:period_type>month</recurrence:period_type>
      <recurrence:start>
        <gdate>2007-07-15</gdate>
      </recurrence:start>
    </gnc:recurrence>
  </sx:schedule>
  <sx:deferredInstance>
    <sx:last>
      <gdate>36871-04-27</gdate>
    </sx:last>
    <sx:rem-occur>0</sx:rem-occur>
    <sx:instanceCount>145601156</sx:instanceCount>
  </sx:deferredInstance>
</gnc:schedxaction>
Comment 2 Volker Englisch 2008-12-30 05:16:04 UTC
Today was the first time that I've been setting a SX to 'Postponed' instead of 'Remind' or 'Ignored' since I'm running GC 2.2.8 (SVN R17777).
After modifying a TX in the register GC crashed with a Segmentation fault and after restarting GC some of the previously 'Postponed' transactions displayed incorrect dates:
   2008-12-01  changed to  27194-12-01
   2008-12-28  changed to   2004-04-14

At this point I would suggest to disable the option 'Postponed' since because it might cause more damage then good (but that's just my personal opinion).
Comment 3 Peter Sewell 2010-02-04 22:24:13 UTC
I have also found this same problem today. I'm running version 2.2.9.

I postponed a scheduled transaction as I didn't want to enter that transaction this month and it disappeared to the bottom of the list with a year which was 4848 way outside my own lifetime!

I hope that this can be sorted in a future update.
Comment 4 Volker Englisch 2010-02-05 15:02:59 UTC
The problem still exists with the following version:
  GnuCash 2.3.7 development version
  Built 2009-10-07 from r18374
Setting the status back to 'Remind' doesn't display this side-effect of the date.
Comment 5 Ashok 2010-07-24 12:26:48 UTC
I ran into this problem in the following version:
  GnuCash 2.3.14 development version
  Built 2010-06-06 from r19233
  running on Win XP Pro SP3.
1. This happened after I set an SX to 'Postponed'.
2. The postponed date 07/15/2010 became 08/14/6905 in the 'Since Last Run...' dialog.
3. In the created transaction it showed the date as 65/88/7564. Once the transaction is selected, the date display changed to today's date. However, it didn't save today's date. Instead it saved 89/88/7788.
4. Got the following error on quitting: 
"There was an error parsing the file file:[name of my accounts file with full path]"
5. Got the same error on trying to reopen the file. Had to go back to an earlier .xac backup file.
Comment 6 Volker Englisch 2011-04-06 03:50:16 UTC
The problem still exists in GC 2.4.3 (Built 2011-03-06 from r20379).

Unfortunately, the only way I know to correct those wacko dates is to hand edit the data file.
Comment 7 Gour 2012-03-16 20:56:49 UTC
Created attachment 209957 [details]
diff showing the changed state after postponing several SXes
Comment 8 Gour 2012-03-16 20:59:32 UTC
I've similar problems with SXes in GnuCash 2.4.10 (built from r21973) on my
x86_64 archlinux machine.

Today I again I postponed some of the SXes and created only one of the
scheduled ones, but GC marked all of them as 'last occurr' on the same date as
the one which was created and is registered in the appropriate account, why all
the others are not really created, although marked as completed in SX editor
which now does not display any transaction as scheduled.

Last time I had similar problem and GC even crashed, so after restarting it I
notice strange numbers in the dates of SXes as reported in the original report.

In the attachment I provide diff (I keep my *.gnucash files under DVCS) from
where it could be seen what did change since my last commit.

While looking for a similar bug report prior to submitting my bug report,
besides this one, I also found another bug report
https://bugzilla.gnome.org/show_bug.cgi?id=634216 which confirms that at the
present moment handling of SXes in GC, or, at least, post-pone function is
quite buggy and should be, maybe, disabled?

Fortunately, we keep our files under DVCS, so with some fiddling we'll be
hopefully able to restore our financial records to the proper state.



Sincerely,
Gour
Comment 9 Geert Janssens 2015-02-11 10:16:09 UTC
This may be a duplicate of bug 672760 which will be fixed in 2.6.6.

Windowws users could already test this by downloading and installing a recent nightly build from http://code.gnucash.org/builds/win32/maint/

Or if you know how to build gnucash on linux, you can build the maint branch to run the same test.
Comment 10 John Ralls 2015-09-21 22:57:15 UTC
Thanks for taking the time to report this.
This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

*** This bug has been marked as a duplicate of bug 672760 ***
Comment 11 John Ralls 2017-09-24 22:04:57 UTC
Reassign version to 2.4.x so that individual 2.4 versions can be retired.
Comment 12 John Ralls 2018-06-29 22:07:43 UTC
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=543212. Please update any external references or bookmarks.