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 634678 - Scheduled transaction calendar not working properly
Scheduled transaction calendar not working properly
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: Scheduled Transactions
unspecified
Other All
: Normal normal
: ---
Assigned To: Christian Stimming
Depends on:
Blocks:
 
 
Reported: 2010-11-12 12:22 UTC by Cristian Marchi
Modified: 2018-06-29 22:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Dates not corresponding-1 (91.91 KB, image/png)
2010-11-12 12:22 UTC, Cristian Marchi
Details
Dates not corresponding-2 (92.12 KB, image/png)
2010-11-12 12:22 UTC, Cristian Marchi
Details
File to test bug 634678 (7.93 KB, application/octet-stream)
2010-11-13 08:36 UTC, Cristian Marchi
Details

Description Cristian Marchi 2010-11-12 12:22:17 UTC
Created attachment 174321 [details]
Dates not corresponding-1

I think I've found a bug in the Scheduled transaction editor. The calendar is not working right when displaying the scheduled transactions day (see attached images). 

If you look to the scheduled transaction details you can see that the transaction "Imposta di bollo su estratto c/c" is scheduled in the right dates (the first day of the month every 3 months).

When I look to the summary calendar in the main window of scheduled transaction editor that same transaction is scheduled in the wrong dates.



The images comes from win XP running GnuCash 2.3.16 (nightly build of a couple of days ago).



Same happens under linux with 2.2.9 and 2.3.16 versions.
Comment 1 Cristian Marchi 2010-11-12 12:22:45 UTC
Created attachment 174322 [details]
Dates not corresponding-2
Comment 2 Christian Stimming 2010-11-12 14:38:41 UTC
The scheduled transaction (SX) calendar for sure has still quite a number of errors. One of them was with SX which had a maximum "number of occurrence" set, and the bug was that the last occurrence didn't show up. I recently fixed this in http://svn.gnucash.org/trac/changeset/19756

Another bug I've noticed is that if the number of occurrence is decreased, this change isn't applied in the respective calendar.

Can you create a very simple example file with exactly the SX that isn't displayed correctly? The function or malfunction depends quite a lot on the exact details of your SX.
Comment 3 Cristian Marchi 2010-11-13 08:36:39 UTC
Created attachment 174376 [details]
File to test bug 634678

As requested I attach a simple gnucash file. To reproduce the problem go to the SX tab and double click on the "Canone mensile c.c." entry in the upper pane. Then click "ok" to close the SX editor without making any change. The calendar will be updated with the right dates for this SX (8th day of any month). Now double click the "Assicurazione autista" entry anda click again "ok" without making any changes. The calendar will be updated and the previous SX named "Canone mensile c.c." is shifted to 9th day of the month in some months.
Tested in both 2.2.9 and 2.3.16 under Ubuntu 10.04 64bit.
Comment 4 Frank H. Ellenberger 2010-11-18 04:49:33 UTC
Could this be a variation of the timezone bug 137017 caused by the end of the DST - all transactions entered in the summer are shifted one day, when displayed in the winter? 
Do we use different functions to extract the date?
Comment 5 Frank H. Ellenberger 2010-11-18 05:15:22 UTC
Looking in your file, I see in SX, they are defined correctly as <gdate>2009-05-08</gdate>. 

In <gnc:transaction> the last entry has 
  <trn:date-posted>
    <ts:date>2010-11-08 00:00:00 +0100</ts:date>
  </trn:date-posted>
That before has
  <trn:date-posted>
    <ts:date>2010-10-08 00:00:00 +0200</ts:date>
  </trn:date-posted>
, but now you are in the timezone UTC+0100 and so, I would expect, it would be  recalculated to
    <ts:date>2010-10-07 23:00:00 +0100</ts:date>
But the second day shift, I can not explain.
Comment 6 Frank H. Ellenberger 2010-11-18 05:23:14 UTC
Ah, this is 2011? Just an idea: If it moves one day between month 10 and 11 this year, why not also next year?
Comment 7 Geert Janssens 2011-06-10 14:07:36 UTC
The patch from bug 652193 seems to fix this problem as well. I can't reproduce this as of trunk r20746. r20745 still shows this problem though.

Can you test as well ?
Comment 8 Cristian Marchi 2011-06-10 18:54:15 UTC
I've just compiled the GC code under ubuntu 10.10 and the problem is gone. With an older version I can reproduce the steps described in comment #3. So I think that this problem is now solved. Thanks for the good work!
Comment 9 Geert Janssens 2011-06-10 20:07:51 UTC
Thanks for the confirmation. I have backported the patch to the 2.4 branch in r20749 so it will appear in the next stable release.
Comment 10 John Ralls 2018-06-29 22:47:09 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=634678. Please update any external references or bookmarks.