GnuCash
Contact   Instructions
Bug 797858 - Transaction date is one day too early from SWIFT MT940 import
Summary: Transaction date is one day too early from SWIFT MT940 import
Status: RESOLVED FIXED
Alias: None
Product: GnuCash
Classification: Unclassified
Component: Import - Other (show other bugs)
Version: 4.0
Hardware: PC Linux
: Normal normal
Target Milestone: ---
Assignee: import
QA Contact: import
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-07-15 15:06 EDT by Jan Vlug
Modified: 2020-07-19 09:37 EDT (History)
3 users (show)

See Also:


Attachments
SWIFT MT940 test file to import (546 bytes, text/plain)
2020-07-15 15:07 EDT, Jan Vlug
no flags Details

Description Jan Vlug 2020-07-15 15:06:15 EDT
When I import a SWIFT MT940 file, the dates of the transactions are imported in a day too early in GnuCash.
See the attached SWIFT MT940 file as test. The date of the transaction is 27/1, but after import in GnuCash the date is 26/1 in GnuCash.
Comment 1 Jan Vlug 2020-07-15 15:07:06 EDT
Created attachment 373790 [details]
SWIFT MT940 test file to import
Comment 2 Jan Vlug 2020-07-15 15:08:30 EDT
See also bug 797848.
Comment 3 Jan Vlug 2020-07-15 15:44:40 EDT
As I was reading bug 137017, I thought that it might be useful to say that my timezone is CEST.
Comment 4 Jan Vlug 2020-07-18 08:53:04 EDT
As suggested in bug 137017 comment 43, I ran GnuCash as follows:
$ TZ=ADT+3 gnucash

And then I tried the import again.
This resulted in a correctly imported date.

So, I think that this issue is more time zone related than aqbanking related.
Comment 5 John Ralls 2020-07-18 18:08:31 EDT
It is a timezone problem but it's AQBanking's time zone problem: The function GWEN_Date_ToTimeT uses the current (as in today's) offset to compute the timestamp of midnight local time on the date to GMT instead of the offset that applies on the actual date. That means that a date when Summer Time (aka Daylight Savings Time in the USA) isn't in effect gets a time stamp an hour early if it's imported when Summer Time is in effect and an hour late in the other case. By setting your TZ to a fixed timezone you worked around the error and got the wrong date.

I've worked around the problem by retrieving the day, month, and year from the date and using a GnuCash function to convert it to a timestamp.
Comment 6 Jan Vlug 2020-07-19 09:37:54 EDT
Thanks John!

Note You need to log in before you can comment on or make changes to this bug.