[Kmymoney-devel] Kmymoney - QIF Import Strangeness
aganderson at ukonline.co.uk
Mon Mar 1 17:15:36 CET 2010
On Monday 01 Mar 2010 15:35:55 Jack wrote:
> On 2010.02.28 20:16, aga wrote:
> > In the process of making some changes in my CSV Importer, I produced
> > a QIF file (which is an optional byproduct). To cut a long story
> > short, I produced the qif QString date, from a QDate, without field
> > separators. On importing the QIF file, I wasn't asked about the date
> > format and KMM imported the file.
> > However, the dates were incorrectly decoded, possibly because, as it
> > happened, all dates in the file were ambiguous.
> > For instance, 30112009 appeared as 20.09.3011, and 29012010 appeared
> > as 20.10.2901. The fact that the dates were accepted suggests that
> > KMM does not insist on field separators, but then in this case,
> > misinterprets the dates. There were nine dates in the file, all
> > within the above range.
> > This is on 3.95.
> I'm not sure what your question is. Without knowing how KMM actually
> read (or tries to read) dates, it looks like its default is YYYYMMDD as
> long as it produces valid results. Personally, I generally prefer this
> format anyway, since you can sort on it easily (text or alpha, with or
> without field separators). Do you have any reason not to use this
> format in the QIFs you produce?
Going back a year or so, it was necessary to specify your input file date
format in the KMM profile. If also was necessary in some cases to provide a
filter script if the provided formats didn't suit. Thomas then revised things
to attempt to determine the format and separators by scanning the input file,
and only asking the user if it couldn't make a good decision.
In the example I quoted, KMM appears to have accepted the fact that there were
no field separators, and attempted to determine the date field layout. My
thought was the analysis of the input file format should have indicated that
the date details were ambiguous and prompted the user to make a choice, but it
didn't do this.
In my importer, I chose not to force the user to adopt a particular date
format, but rather to ask the user about his input file, and to input into KMM
in QDate format, where the locale format would result. For the QIF file, I
use the same date field layout as in the input file, although with a '/' slash
So far as my particular minor issue is concerned, I've added back in the field
separators I had removed so I don't any longer have a problem. However, there
still remains a query about KMM's date analysis, which is why i highlighted
the issue. When I first saw the data in KMM, my first thought was, "I've
screwed up again." However, the qif file was OK, and I realised the problem
was with the dates themselves, or rather the dates combined with the absence
More information about the KMyMoney-devel