GNOME Bugzilla – Bug 598788
Cannot set date 2009-10-11 in transactions
Last modified: 2018-06-29 22:29:55 UTC
I can't add or change transactions on date Sunday 2009-10-11. The behaviour is exactly the same described by Daniel Duran in bug 486461. I tried version 2.3.7 and it has the same problem. I'm using Windows Vista Business 32-bit in English but located in Chile.
I also tried it in other PC with Windows XP Professional and it has the same problem. Furthermore, I think the same behaviour occurs for the second or third Sunday of October of every year. For example, I also couldn't use the dates: 2005-10-09, 2006-10-15, 2007-10-14, 2008-10-12, 2010-10-10, 2011-10-09, 2012-10-14, 2013-10-13.
In my second job as a full time programmer I worked for US Trust of NY where I was given responsibility for a stock price and investment monitoring system. The system which ran flawlessly for three years mysteriously crashed one day in the month of October. After carefully examining the Fortran code (shows you how long ago this had occurred) I discovered that the system would crash if Halloween of a leap year occurred on a weekend. This is how the bug developed: (1) A stock's growth rate calculation was based on the closing stock price on Halloween, where the Halloween closing price was divided into an exponential average price. (2) If Halloween fell on a weekend the price of the stock defaulted to zero. The price was then adjusted to the last valid closing price if the Halloween price was zero. However, if the Halloween price was zero during a leap year (in a leap year the growth rate algorithm is slightly different) the original programmer forgot to adjust the price to the last valid non-zero price. (3)Therefore, we had a divide by zero condition if Halloween of a leap year fell on a weekend. Use your linux cal command to see in which year this had occurred (and don't call me grandpa). Anyway, it just sounded like my "favorite" bug was similar to the bug discovered in 598788
I can't reproduce this on Windows XP (Home) here with either 2.2.9 or 2.3.10. Just some random suggestion: can you try to change the date format used by GnuCash, and test if the problem persists ? You can do this via Edit -> Preferences -> Date/Time. Try different date formats here and see what happens.
*** Bug 632409 has been marked as a duplicate of this bug. ***
The reporter on 632409 reports the same behavior on 2.3.15 under Win7 Pro 64.
For the record, the reporter of bug 632409 also tried with different date formats as suggested in comment 3, but the problem remains.
*** Bug 632367 has been marked as a duplicate of this bug. ***
This is happening to me (Windows 7 Starter Edition). Here in Brazil, Daylight Saving Time started Oct-16. Gnucash doesn't let me choose this day for my transactions.
No, it doesn't. I don't know if Win7 lets you adjust it, either -- but that's a useful clue. Can you attach a tracefile [1] from failing to edit a transaction? [1] http://wiki.gnucash.org/wiki/Tracefile
John, got the tracefile, but I guess nothing very useful came from it (even with --debug --extra). First, though, a little bit on how I'm setting the date. Using +: date will refuse to ascend from Oct-15 Using -: date skips from Oct-17 to Oct-15 Entering manually: date becomes Oct-15 When I hit the date using +/-, unfortunately nothing shows up in tracefile. When entering manually, upon hitting enter this chunk appears: http://pastebin.com/GAxXTeGA. I feel that the "roadblock" is hit upon merely writing the problematic date, because simply writing "16" on the date field already displays, in the status bar, the Oct-15 date, as shown here: http://img254.imageshack.us/img254/2141/oct16.png Hope this helps!
Does that chunk in the tracefile turn up regardless of date, or only on the 16th?
John, that would be regardless of date.
Rats. So we've got Windows, end of DST, and Latin American temporal locales in common.
It's beginning of DST here, John. I reckon you're having a hard time deducting the root cause from such distance. I'm considering setting up a dev environment for Gnucash in order to step-by-step through the bug - do you think this would be too hard, and would you find this useful?
Beginning. Southern hemisphere. Right. I'm afraid that I'm going to have to leave this to Geert or Christian, as I'm not at all familiar with Windows system calls. If you're able to debug it, yes, you have a much better chance of finding (deducing -- deducting is something you do to money, as in a tax deduction -- ain't English fun?) as it's hard for us to replicate all of the nuances of your environment. If you're comfortable with command-line development, it's not too challenging, and there's a shell script to do most of the work. See http://wiki.gnucash.org/wiki/Windows#Instructions_for_an_.28almost.29_automated_build for instructions.
Hi John, I'm officially giving up debugging this for now. Building Gnucash in Windows has been a challenge, because the instructions lack A LOT and I had to tweak the source in so many ways. I haven't managed to build completely (guile is complaining about something) and haven't got the time to look further into this anymore. There's been some weeks this has been "on halt" in my PC, but I just wanted to let you know. Thanks for the assistance (technical and ortographical)!
This came up on the user's mailing list and I decided to do a little test. I set the timezone in Windows to Asunción and tried to enter a 6 October 2013 date in the just-released Gnucash-2.5.6. No problem. Uninstalled 2.5.6, installed 2.4.13, tried again. Wouldn't let me: Moved the date to 5 Ocotber. 6 October is the day this year that Paraguay started summer time. So the problem is fixed, I guess by the rewrite of gncdate to deal with the 2038 bug. I'm not going to try to backport that rather massive set of changes to 2.4 to make sure, though.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=598788. Please update any external references or bookmarks.