OFX Encoding bug - This time from CBA

Further to my discover of a financial institution failing to generate OFX standard compliant OFX file, while I was helping a friend to download bank statements from the Commonwealth Bank of Australia's Netbank facility, I noticed something not quite right.

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 3.2.8.2 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:

File-01:
20120937021837
20120937021837
20120937021837

File-02:
20120945030545
20120945030545
20120945030545

File-03:
20120950015650
20120950015650
20120950015650

File-04:
20120948021348
20120948021348
20120948021348

According to the standard, section 3.2.8.2, 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.