Implementation notes:

Two-way communication support (Bill payment, etc.):
LibOFX is designed to support OFX responses only.  Typically the user will download an OFX "file" from his bank.  To my knowledge, this is the
first working OpenSource OFX implementation.  Off course, OFX is meant to support much more than statement and transaction download.  The spec
defines method for bill payment, bill presentment, scheduling payments, recurring transaction, email communication with the financial
institution and more.  However, we have to start somewhere.  Also, most banks only allow e-banking from their own web interface.  The do not
accept direct ofx commands.  In any event, I do not have access to a bank that does, and for that reason I am unable to work on implementing
these features.

Date handling:
-The library always returns the time in the systems local time
-OFX defines the date up to the millisecond.  The library ignores those milliseconds, since ANSI C does not handle such precision cleanly.  The
date provided by LibOFX is precise to the second, assuming that information this precise was provided in the ofx file.
-DEVIATION FROM THE SPECS : The OFX specifications (both version 1.6 and 2.02) state that a client should assume that if the server returns a
date without à specific time, we assume it means 0h00 GMT.  As such, when we apply the local timezone and for example you are in the EST
timezone, we will remove 5h, and the transaction will have occurred on the prior day!  This is probably not what the bank intended (and will
lead to systematic errors), but the spec is quite explicit in this respect (Ref:  OFX 2.01 spec pp. 66-68)
To solve this problem (since usually a time error is relatively unimportant, but date error is), I decided to use the following behavior:
  -If no specific time is given in the file (date only), the transaction is assumed to have occurred 12h00 (noon) GMT.  This way, we will never
change the date, since in any event we didn't know when in the day the transaction occurred in the first place. We assume that if the
transaction was timezone sensitive, a proper time, with timezone would have been specified.
  -If no timezone is specified, but exact time is, the timezone is assumed to be GMT, following the spec.
  -If a timezone is specified, it is used to properly convert in local time.