I hate to interrupt but wouldn't it make more sense to have a format string
field somewhere in the system that the user would specify (with a default of
m/d/y)? For example, it would interpret m.d.y or d.m.y or any other system
based on the three tokens (d, m, and y).
This wouldn't to be that hard to implement and it isn't too criptic for a
reason user (reasonable being someone with a few months experience with
using computers).
I guess what I'm suggesting is (forgive me if it already exists) a
properties box for the QIF import/export routines. That box would have the
field I mentioned and anything else that might vary.
Daniel
> -----Original Message-----
> From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, August 17, 1999 5:46 PM
> To: Peter Pointner
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: QIF import from Quicken 8 (german version)
>
> On Tue, 17 Aug 1999 23:39:00 +0200, the world broke into rejoicing as
> Peter Pointner <[EMAIL PROTECTED]> said:
> >
> > I just started to look at gnucash. I wanted to have some stuff to play,
> > and I QIF-exported a file from Quicken 2000 (aka Quicken 8), german
> > version. Btw, at least this version allows to export all accounts to one
> > QIF file.
> >
> > Then I imported the QIF-file to gnucash: All transactions get a date of
> > 1/1/1970. Looking deeper, I noticed that gnucash expects the date fromat
> > to be month/day/year, while my QIF-file contains month.day.year
> >
> > To solve that, I would fix gnucash _if_ the QIF-file is valid. If not, I
> > would write a utility to fix the QIF-file. Somehow I suspect that the
> > QIF-file is broken: The dot is a german date separator, but the order
> > m.d.y is not what we use here. And it doesn't make much sense to use
> > localized date strings in things like QIF-files. (And this quicken
> version
> > is full of bugs anyway. This in combination with Intuit being totally
> > uninterested in any feedback is why I look at gnucash.)
> >
> > Since I could not find a spec for valid datestrings in QIF-files, I ask
> > here: Should gnucash be fixed, or should I fix the QIF-file?
>
> GnuCash does indeed need to be fixed.
>
> I have code that should cope with the unexpected ordering of dates,
> although not (yet) the use of dots rather than slashes.
>
> I'm trying to head towards the initial "version that kind of works"
> at this point; it is a bit early to start trying to collect samples of
> diverse QIF files.
>
> The simple answer for you today is to write a little utility that fixes
> the dates so they look like the US-centric QIF format.
>
> Longer term, I would like to handle that automatically in the import
> process.
>
> --
> "There's nothing worse than having only one drunk head."
> -- Zaphod Beeblebrox
> [EMAIL PROTECTED] <http://www.ntlug.org/~cbbrowne/lsf.html>
> ----- %< -------------------------------------------- >% ------
> The GnuCash / X-Accountant Mailing List
> To unsubscribe, send mail to [EMAIL PROTECTED] and
> put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
----- %< -------------------------------------------- >% ------
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
