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 792106 - Wrong dates displayed
Wrong dates displayed
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: Register
2.7.x
Other Windows
: Normal critical
: ---
Assigned To: gnucash-ui-maint
gnucash-ui-maint
: 792175 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2018-01-01 21:41 UTC by Alen Siljak
Modified: 2018-06-30 00:02 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Alen Siljak 2018-01-01 21:41:31 UTC 
Version 2.7.3, Windows 10

I have a couple transactions entered today, on 2018-01-01 with 2.6.19.

After opening the database in 2.7.3 those are displayed in the register with the date 2018-10-13.

The transaction post date is 20180101105900
and enter_date is 20171112033316.

This has been entered from a recurring transaction. That would explain the enter date being so far in the past.
Comment 1 Alen Siljak 2018-01-01 21:56:46 UTC 
There are definitely NO splits with 2018-10-13 date in the Splits table.
This is in a sqlite3 book.
Comment 2 Alen Siljak 2018-01-01 21:58:12 UTC 
I see what might be going on. My date fields are still 14-bytes long. Could be a database issue.
Comment 3 Alen Siljak 2018-01-01 21:59:21 UTC 
Splits.reconcile_date is 14-bytes
but
Transactions.post_date and .enter_date are 19.
Comment 4 John Ralls 2018-01-04 01:01:41 UTC 
*** Bug 792175 has been marked as a duplicate of this bug. ***
Comment 5 Fabio 2018-01-04 01:03:36 UTC 
I'm also affected by this bug.
As a workaround I wrote a python script to change the format of all dates to the new ISO format in my file.
Comment 6 John Ralls 2018-01-04 01:18:25 UTC 
Reminder: 2.7.3 is an UNSTABLE release. While I'm very grateful indeed that you're testing it, you should continue to use 2.6.19 for keeping your real books and use 2.7.3 only for testing on a *copy* of your books.

Note very well that opening a SQLite3 database with 2.7.3 sets a flag that will stop you from being able to open that database in 2.6.19 precisely because of this date format change... the adaptive code will not be released until 2.6.20.
Comment 7 Alen Siljak 2018-01-04 09:16:53 UTC 
@Fabio, I created a simple SQL script that does this either way (2.6 -> 2.7 and back), in case somebody else finds it useful during testing:

https://github.com/MisterY/gnucash-portfolio/blob/master/utils/dates_to_26.sql
Comment 8 John Ralls 2018-01-10 01:29:33 UTC 
Fixed in git. I'd mistakenly believed that boost::date_time would return not-a-date-time if the string supplied to operator>> didn't match the format supplied to the input facet. No such luck, so now I do a simple test on the string first and set the format accordingly. It should be faster and with some regexes should make for a more flexible system.
Comment 9 John Ralls 2018-06-30 00:02:25 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=792106. Please update any external references or bookmarks.