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 791848 - GC 2.6.x does not handle ISO dates introduced with GC 2.7
GC 2.6.x does not handle ISO dates introduced with GC 2.7
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: Backend - SQL
2.7.x
Other Windows
: Normal critical
: ---
Assigned To: gnucash-core-maint
gnucash-core-maint
Depends on:
Blocks:
 
 
Reported: 2017-12-21 14:57 UTC by Alen Siljak
Modified: 2018-06-30 00:01 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Alen Siljak 2017-12-21 14:57:03 UTC 
GC 2.7(.2) extends the date fields so that they can store dates in ISO format. All new records contain dates in the new format and the application handles both new and old records fine.

However, this is not backwards compatible as GC 2.6(.19) shows 1970-01-01 for any date stored in ISO format.
Comment 1 Alen Siljak 2017-12-21 19:31:38 UTC 
What I forgot to mention here, and is useful for reference, is that I'm referring to sqlite backend. Not sure how other db storage types are affected.

OT: Looking forward to that query system update!
Comment 2 John Ralls 2017-12-23 00:42:54 UTC 
Actually it looks like it's not forward-compatible, either: GnuCash 2.7.2+ crashed on me when I tried to open a SQLite3 database created in 2.6.
Comment 3 Alen Siljak 2017-12-23 03:09:30 UTC 
I have to say that I did not experience that issue. I was using my production file (!) and everything seemed fine with the dates in 2.7.2.
The testing was not extensive but I was entering transactions for a couple of days.
Comment 4 John Ralls 2017-12-28 21:33:33 UTC 
This is more-or-less fixed for 2.6.20 and 2.7.3 in that opening a SQLite3 database in 2.7.3 will set a feature that will cause any version older than 2.6.20 to open it read-only. The dates on all of the transactions will be invisible, having not been read.

It would have been better for 2.7.3 to set that feature only if it wrote to the database but it turns out that the way we construct core objects (Transactions, Splits, etc.) triggers the commit code and with the current design there's  no way for the backend to tell the difference thanks to a deficiency in the way GObject classes are constructed. The C++ rewrite of the core classes will fix that by providing proper constructors.
Comment 5 John Ralls 2018-06-30 00:01:57 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=791848. Please update any external references or bookmarks.