> On Jun 9, 2017, at 2:05 AM, Okkie <gnuc...@okkie.nu> wrote: > > On 06/09/2017 01:50 AM, John Ralls wrote: >>> On Jun 8, 2017, at 7:56 AM, Okkie <gnuc...@okkie.nu> wrote: >>> >>> [...] >>> >>> The difference / extra info here is: >>> >>> * gnucash did not crash. I shut down the previous version gracefully. >>> * This particulair transaction has been there for almost 12 years now. >>> * It is the very first transaction in this particular account. >>> * A quick look in a backup from 6 month's ago also shows: post_date: >>> 0000-00-00 00:00:00 >>> * This never caused trouble while starting up before. >>> >>> So.. maybe it is a regression issue that may bite others too? >> Not exactly a regression. GnuCash should never have accepted a transaction >> with a post date from the reign of Octavian, though crashing isn’t an >> acceptable response either. > > Hehe. Maybe I shouldn't call it a regression, but none of the previous > versions dumped core on this entry. What makes matters worse is that it > needs a start from the command line to see if there's a useful error. A > GUI-only user only sees a splash screen that disappears after a while. And > even with the error, you need to have quite some skills to find the cause. > Thank you, Sahib Jakhar for finding it and posting it to this list! Saved me > a lot of time! > > Maybe Sahib's first crash was not in any way related to this entry, but just > a trigger to start up into the new version. Sahib, are you also running > Ubuntu? Can you check in /var/log/apt/ if gnucash got upgraded during the > uptime of the session that eventually crashed? > > From my history I found the following updates: > > 2017-01-30 gnucash 1:2.6.12-1 > 2017-05-29 gnucash 1:2.6.16-1~getdeb1 > > The .12 version was restarted a few times and was still running for a few > weeks when I restarted the computer and started .16 for the very first time. > > > >> How long ago did you switch to the SQL backend? That wasn’t available in >> 2005. I don’t suppose you have any of the old XML files around to see if the >> transaction was actually created with no post date. > > Well, sometimes not cleaning up can be a good thing. Apparantly I still have > the backup from before the conversion hanging around in a subdirectory. > > I migrated in december 2013, and in the last XML I see this next to the same > guid: > > <trn:date-posted> > <ts:date>1970-01-01 00:00:00 +0100</ts:date> > </trn:date-posted> > <trn:date-entered> > <ts:date>2005-09-09 16:21:36 +0200</ts:date> > </trn:date-entered> > > So even then, there was already a zero date (0s since the epoch) in this > transaction. > > Does this help in any way?
Hmm. That shows an error in the SQL date conversion: 1970-01-01 is obviously not 0000-00-00. It turns out that before the 2038 bug rewrite time_t 0 and negative time_ts were considered invalid dates and deliberately set to NULL in the SQL backend. Somewhere along the line MySql seems to have written those NULLs out as 0000-00-00. I've removed that code from the SQL backend because time_t 0 (now time64 0) is a perfectly legitimate date. I've also now fixed the crash that I was supposed to have done for 2.6.16, so any date before the date system's minimum gets converted to 1970-01-01 00:00:00 UTC and any later than the date system's maximum gets clamped at the date system maximum. Regards, John Ralls _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-user ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.