BUG report - Date Format in qif? it may be invest type, if the Q line has comma separator

[Bob]

>> I am having trouble importing my qif file into gnucash 1.6.2 -
>> it finds the date format ambiguous but gives no options in the date
>> format dropdown box. I am thinking of writing a Perl script to change
>> the dates into a less ambigous format. My question is : what is the=20
least
>> ambiguous format the dates can have in a qif file, if there is such a=20
thing?

>My guess is that the date format is inconsistent, not ambiguous, but for
>some reason the importer's getting confused about it.  Make sure all of
>your dates are in the same format .. where format just means the
>ordering of the date-parts (month, day, year).  For added clarity you
>can have the years completely written out (2001 instead of 01).  If you
>have the year completely written out and at least one transaction
>occurring after the 12th of the month there's no way there can be
>ambiguity.

Using Quicken Deluxe 98.

I've been trying to get my QIF files imported to Gnucash 1.6.2, but had=20
problems.  I upgraded to 1.6.4 and still have the problems.

(wasn't too easy to upgrade in Redhat 7.2 either - I finally had to=20
download the 1.6.4-1.src.rpm and perform an "rpm --rebuild=20
gnucash-1.6.4-1.src.rpm" to fully rebuild it using my current pkg setup ,=
=20
which actually hung my machine during a C compile involving guile-util.c=20
when I did it in a shell window in X - with 100% CPU going!!!! but on=20
reboot I was able to do it after logging on but not going into X, - it=20
did work eventually.  I did find an rpm for 6.4.1 that gave no dep=20
problems, but I wanted postgresql support to try it and only a version=20
with Guile 1.4 had that and that one would no way work with Redhat 7.2)

It turns out that the import gets confused when an investment account has=
=20
a transaction where the quantity is > 999.  Seems like it can't decide=20
what the currency separators should be.  I have traded warrants and the=20
quantities tend to be large.  The very first transaction looked like:

!Type:Invst
D3/19/91
NBuyX
YMy Warrant
I0.2815
Q10,000     <<BUG HERE>>
U2,815.00
T2,815.00
MInitial Purchase
L[Business]
$2,815.00
^

In the above, notice that Q10,000 has the comma for thousands, but no=20
period for decimals since its not money.  The following line has 2,815.00=
=20
for US currency.  The import gets confused by this and brings up a=20
misleading dialog to the effect that the date isn't recognized and please=
=20
select - except that the selection box is blank!  To make it worse, if=20
you select <next> instead of <back>, it crashes.

If you change all Investment Q lines with > 999 to look like money, e.g.=20
above would be "Q10,000.00", then the import accepts it.

The alternative, that also works, is to change it to have NO separators,=20
"Q10000".

Note that I have just found this and have had a long day, so I haven't=20
yet actually performed the import to see if the transaction is entered=20
correctly or not.  It is possible that it is better to take the comma=20
away rather than add the decimal point, but I don't know at this time.

Hope this helps someone,
  Bob