One would think CBA being one of the largest banks in Australia would have hired the most competent developers to code their download statement in OFX format. Well it seems their developers have failed the test of standard software development practice producing ridiculous results, just like others.
In CBA's case, it seems that they have not read section 126.96.36.199 of OFX 1.02 specification for representing datetime.
In 4 files out of 13 I downloaded, in a space of a day, the elements <SONRS><DTSERVER>, <LEDGERBAL><DTASOF> and <AVAILBAL><DTASOF> containing ridiculous dates and here are the figures:
20120937021837 20120937021837 20120937021837
20120945030545 20120945030545 20120945030545
20120950015650 20120950015650 20120950015650
20120948021348 20120948021348 20120948021348
According to the standard, section 188.8.131.52, which says:
Tags specified as type date or datetime and generally starting with the letters “DT” accept a fully formatted date-time-timezone string. For example, “19961005132200.124[-5:EST]” represents October 5, 1996, at 1:22 and 124 milliseconds p.m., in Eastern Standard Time. This is the same as 6:22 p.m. Greenwich Mean Time (GMT).
Date and datetime also accept values with fields omitted from the right. They assume the following defaults if a field is missing:Note that times zones are specified by an offset and optionally, a time zone name. The offset defines the time zone.
Take care when specifying an ending date without a time. If the last transaction returned for a bank statement download was Jan 5 1996 10:46 a.m. and if the
was given as just Jan 5, the transactions on Jan 5 would be resent. If results are available only daily, then just using dates and not times will work correctly.NOTE: Open Financial Exchange does not require servers or clients to use the full precision specified. However, they are REQUIRED to accept any of these forms without complaint.
Some services extend the general notion of a date by adding special values, such as “TODAY.” These special values are called “smart dates.” Specific requests indicate when to use these extra values, and list the tag as having a special data type.
So how can any developer possibly produce 37, 45, 50 and 48 days in September? Do they actually test their code at all? I wonder if these people has actually read the standard before coding?
Thankfully GnuCash does not use these elements otherwise it will prevent the download data from being imported into GnuCash.