Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#39 imports incorrect date

open
nobody
5
2013-02-15
2012-11-18
HomeBank
No

This is related to Homebank bug #1080093
https://bugs.launchpad.net/homebank/+bug/1080093

The attached OFX file includes 2 transactions — one on 28 October and one on 29 October. Both are imported with the date 28/10/12.

28/10/12 is end of BST in the UK, so it is likely to be a timezone bug in libofx. Interestingly, it only has an effect on dates after the end of DST in a given year (i.e. dates before 25 March are fine).

The correct date is displayed if the time component is set to 01:00:00.

O/S: Ubuntu 12.04
HomeBank version: 4.4
libofx version: 1:0.9.4-2
Timezone: Europe/London

Discussion

  • HomeBank
    HomeBank
    2012-11-18

     
    Attachments
  • Date interpretation according to ofx specification

     
    Attachments
  • What you are seeing is the proper behaviour according to the ofx spec (see atached file): Dates without hours, minutes and time zone are to be interpreted as midnight, GMT (which never changes DST). As london has no offset with GMT for half the year, you see a date change.

    The spec is probably not optimal. So we implemented a workaround (http://libofx.sourceforge.net/html/fx-0_86_85_2lib_2ofx__utilities_8cpp.html#a2). Why it's not working in your case I don't know yet.

    The root problem is that sending a date without a time for an electronic transaction is really stupid. Unfortunately, banks, despite their huge resources, still do a lot of really stupid things with very basic OFX stuff.

     
    • status: open --> open-accepted
     
  • I have hit exactly the same problem. The issue here is that in ofxdate_to_time_t(), there is the following line:

    time.tm_isdst = daylight; // initialize dst setting

    I have no idea why this line even compiles, given that "daylight" is not a declared variable! But anyway, at least on my system, its value is 1, or true, or something like that. That means when the 00:00:00 time is imported into the time structure and used as-is, one hour is deducted by mktime() and so the date is changed.

    In fact, whether DST is in effect or not should be decided on a per-transaction basis, after looking at the date and time of the transaction. I don't get why it's being set unilaterally at the top of the file.

    I understand the problems with spec violations that you are seeing but, as your comment in the file indicates, we should never change the date of a transaction. If the time is set specifically to date X, 00:00:00, then the actual time structure which results after the parsing should represent exactly that, not 23:00 on the previous night.

    Let me know if I can help in any way with this. There are several ways it could be fixed, but I'd want guidance from the maintainer before picking and implementing one.

    Gerv

     
  • BTW, here's a sample file which imports wrongly, with a date which is nowhere near the DST switchover.

    Gerv

     
    Attachments
  • I fixed this for me by changing:

    time.tm_isdst = daylight; // initialize dst setting

    to

    time.tm_isdst = 0;

    Of course, that fix won't keep it working for everyone else. I emailed the author to ask them for guidance on a better fix, but got no reply :-(

    Gerv