GNOME Bugzilla – Bug 769124
Australian (GMT-10) OFX transactions imported have previous days date
Last modified: 2018-06-29 23:50:01 UTC
Split from https://bugzilla.gnome.org/show_bug.cgi?id=767824 There seems to be a problem with the dates of transactions imported by the OFX importer. They all seem to be the day before they should be in GnuCash. E.g. In OFX file: 28 Jun 2016, in GnuCash: 27 Jun 2016. The import seems to be wrong in both 2.6.12 and 2.6.13. They both do the same thing. I'm in Sydney GMT-10 as currently not daylight saving. GMT-11 when daylight saving is in effect. I've only tested in Windows 10, in which my timezone is the usual: (UTC+10:00)Canberra, Melbourne, Sydney All the dates in my OFX file are yyyymmddhhmmss but hhmmss is always 000000. My OFX file is downloaded from Australian ING Direct bank. 2.6.13 : 1) Imported transaction: .ofx: <DTPOSTED>20160628000000 uncompressed .gnucash <trn:date-posted> <ts:date>2016-06-27 00:00:00 +1000</ts:date> 2) Old 2.6.12 entered, not imported transaction : 25/5/2016 is correct <trn:date-posted> <ts:date>2016-05-25 00:00:00 +1000</ts:date> 2.6.12 : 1) Imported in 2.6.12: <trn:date-posted> <ts:date>2016-06-27 00:00:00 +1000</ts:date> 2) Not imported transaction : 25/5/2016 <trn:date-posted> <ts:date>2016-05-25 00:00:00 +1000</ts:date> I'll do some testing to see if this problem also affects QIF and CSV imports. Please let me know if you need more info. Regards, Chris Good
Testing in GnuCash 2.6.13 Windows 10 shows this problem does NOT also affect QIF or CSV imports.
Chris, can you please test with a recent nightly build? I can't replicate this in maint, so it might have been fixed by 51e29e7.
Hi John, Thanks for looking at this. Unfortunately I am still seeing the problem in http://code.gnucash.org/builds/win32/maint/gnucash-2.6.13-2016-08-26-git-ea38624+-setup.exe which should have 51e29e7 as it was committed to maint Jul 13, 2016. Here is my test file with just bank account number obscured: OFXHEADER:100 DATA:OFXSGML VERSION:102 SECURITY:NONE ENCODING:USASCII CHARSET:1252 COMPRESSION:NONE OLDFILEUID:NONE NEWFILEUID:NONE <OFX> <SIGNONMSGSRSV1> <SONRS> <STATUS> <CODE>0 <SEVERITY>INFO </STATUS> <DTSERVER>20160902084749 <LANGUAGE>ENG </SONRS> </SIGNONMSGSRSV1> <BANKMSGSRSV1> <STMTTRNRS> <TRNUID>1 <STATUS> <CODE>0 <SEVERITY>INFO </STATUS> <STMTRS> <CURDEF>AUD <BANKACCTFROM> <BANKID>4321 <ACCTID>12345678 <ACCTTYPE>SAVINGS </BANKACCTFROM> <BANKTRANLIST> <STMTTRN> <TRNTYPE>CREDIT <DTPOSTED>20160831000000 <TRNAMT>6.54 <FITID>910664.20160831.6.54 <MEMO>Bonus Interest Credit - Receipt 910664 </STMTTRN> <STMTTRN> <TRNTYPE>CREDIT <DTPOSTED>20160831000000 <TRNAMT>11.66 <FITID>910664.20160831.11.66 <MEMO>Interest Credit </STMTTRN> </BANKTRANLIST> </STMTRS> </STMTTRNRS> </BANKMSGSRSV1> </OFX> In the GnuCash ofx importer and in the imported transactions, it is 30/08/2016 but should be 31/08/2016. I ran this test just before noon if that is relevant.
If you look at the saved date_posted is the time 21:00 local/11:00Z?
No: 2016-08-30 21:00:00 +1000
Actually, that's "yes": 21:00 local time. This turns out to be https://sourceforge.net/p/libofx/bugs/39/. I'm working up a fix for upstream and a work-around for GnuCash.
This problem has been fixed in our software repository. The fix will go into the next software release. Once that release is available, you may want to check for a software upgrade provided by your Linux distribution.
Hi John, Thanks very much for your help with this. I tested in just released Windows 2.6.14 git rev 3e7022b built on 2016-09-17 (not nightly build) - not fixed. Input file: <DTPOSTED>20160831000000 Imported transaction .ofx <trn:date-posted> <ts:date>2016-08-30 21:00:00 +1000</ts:date> Tested at approx. 10:30am local time. I'm deleting an existing transaction and re-importing. I assume that is a valid way to test. Regards, Chris Good
Hmm. It must have not recognized the libofx bug on the Windows build. I won't be able to look at this until I return home next month.
Yup, that was it. My test script worked OK on Unix but not on Win32. I've pushed a fix, please try tomorrow's maint nightly.
Hi John, The most recent nightly maint build is 2016-10-20 18:39 6695ef9+. 6695ef9 is the same commit as your maint commit for this problem so I assume that is what I should test but it is not fixed. Thanks, Chris BTW, http://wiki.gnucash.org/wiki/Windows#Q:_Where_is_the_binary_installer.3F says: As it is not so easy to build GnuCash under Windows, a weekly build of the stable branch at http://code.gnucash.org/builds/win32/2.4/ is made available as well to test bugfixes. 2.4? There doesn't seem to be a http://code.gnucash.org/builds/win32/2.6. If I can help modifying web site, please let me know.
Sigh. I forgot to reset CMake on the build server. Try http://code.gnucash.org/builds/win32/maint/gnucash-2.6.14-2016-10-22-git-6695ef9+-setup.exe. It's just a stale link in the wiki, it should be http://code.gnucash.org/builds/win32/maint/. I've already fixed it. Thanks for noticing. BTW, only Derek can modify stuff on code except for the contents of git repos.
Sorry, still not working. Now: <trn:date-posted> <ts:date>2016-08-30 20:59:00 +1000</ts:date> BTW, Aus NSW is now on daylight saving.
Rats. I was trying to be a bit too clever, I guess. I've pushed a new change (5fcdfba), should be reflected in tomorrow's build.
It's at http://code.gnucash.org/builds/win32/maint/gnucash-2.6.14-2016-10-24-git-5fcdfba+-setup.exe.
Works Thanks John. <trn:date-posted> <ts:date>2016-08-31 20:59:00 +1000</ts:date>
Yay. That was way harder than it should have been.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=769124. Please update any external references or bookmarks.