Re: QIF/CSV import date parsing code
"Benjamin Sperisen" <[EMAIL PROTECTED]> writes: > So, if you've already started on one, just tell me and I'll start > tracking it. If not, is it alright with you if I write it? It would > probably have a prototype like: > > time_t gnc_parse_date(char* str, int format); > > where format is in an enumeration containing the formats d-m-y, m-d-y, > y-m-d, and y-d-m. (See Derek's email for how it would work: > https://lists.gnucash.org/pipermail/gnucash-devel/2007-July/020948.html) > This does depend, however, on how big of a problem the issue Thomas > raised is > (https://lists.gnucash.org/pipermail/gnucash-devel/2007-July/020950.html). > > In any case, just let me know what you think. I think you need two passes. You need one pass to go through the whole dataset and reduce the choices based on the data, then if there's an ambiguity you should ask the user, and THEN you can go and finish the parsing based on the user input (or go into a CSV profile and check it from there). If you have any questions even after my previous mail let me know and I can go into more detail. I think that this API is certainly reasonable for the second stage. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: QIF/CSV import date parsing code
Thomas Baumgart <[EMAIL PROTECTED]> writes: > You might find some more information about the problem here: > > http://kmymoney2.sourceforge.net/online-manual/details.impexp.qifimp.html#id2512201 Interesting. The way I'd handle it is to assume "70-99" -> 1970-1999 and "00-60" == 2000-2060. If we find a year "61-69" consider it an error because, at least in GnuCash, we can't handle years prior to 1970. This will at least work for the next 50 years, and by then we can hopefully get rid of QIF. ;) I'd prefer not to require the users to set up a profile if I can avoid it. The less a user has to think about it the better, and in the case of QIF there's rarely an issue. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: QIF/CSV import date parsing code
Hi all, on Tuesday 10 July 2007 12:39, Benjamin Sperisen wrote: > Hi Chintan, > > I think I'm at the point with the CSV import where I would be ready to > integrate a date parser that could be used by both the QIF and CSV > imports, so I was just wondering how far you are as far as date > parsing code is concerned. I'm happy to write the date parsing > function, but I thought I better check with you to make sure we don't > independently write the same code twice. ;-) > > So, if you've already started on one, just tell me and I'll start > tracking it. If not, is it alright with you if I write it? It would > probably have a prototype like: > > time_t gnc_parse_date(char* str, int format); > > where format is in an enumeration containing the formats d-m-y, m-d-y, > y-m-d, and y-d-m. (See Derek's email for how it would work: > https://lists.gnucash.org/pipermail/gnucash-devel/2007-July/020948.html) > This does depend, however, on how big of a problem the issue Thomas > raised is > (https://lists.gnucash.org/pipermail/gnucash-devel/2007-July/020950.html You might find some more information about the problem here: http://kmymoney2.sourceforge.net/online-manual/details.impexp.qifimp.html#id2512201 -- Regards Thomas Baumgart GPG-FP: E55E D592 F45F 116B 8429 4F99 9C59 DB40 B75D D3BA - A crash turns an expensive computer into a simple stone! - pgpGZuc0hZCXb.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
