[Kmymoney-devel] Kmymoney - QIF Import Strangeness

aga 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.
> 
> Allan,
> 
> 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?
> 
> Jack

Hi Jack

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 
as separator.

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 
of separators.

Allan






More information about the KMyMoney-devel mailing list