Matthew Vanecek writes:
> Dave Peticolas wrote:
> >
> > Matthew Vanecek writes:
> > > Dave Peticolas wrote:
> > > I went back and reviewed the accounts, searching for differences in the
> > > ones that did and didn't work. After I set the view to the entire date
> > > range, instead of the current year, I noticed that the Opening Balance
> > > on the crashing accounts was dated 12/31/1969. After I changed that to
> > > something more appropriate, things seemed to work OK.
> > >
> > > False alarm or Y2K bug? =P
> >
> > Not Y2K, but definitely a bug. The value being passed to localtime
> > exceeded the limits on the size of a time_t value. As an aside, this
> > has nothing to do with the fact that it's negative. The time functions
> > should handle negative times just fine. It's just that in this case the
> > value's magnitude is too large, and the localtime guile wrapper is
> > refusing to accept it.
> >
> > The date in question (12/31/1969) is being returned by the C routines
> > after truncating the value. You can enter pre-1970 values by hand just
> > fine. The actual date (-4294992496 seconds before 1970) is just too
> > far back in this case.
> >
> > So, the question is, how did that date get into GnuCash? I'm guessing
> > that opening balance transaction was created by a qif import. Which
> > version of GnuCash did you use to import the qif? Do you still have
> > the qif?
> >
> > thanks,
> > dave
>
> I used 1.3.7 to perform the import. Once again, the .qif was exported
> by Moneydance (2.0.4). For whatever reason, Moneydance records an
> "Opening Balance" transaction in the .qif. I'm not sure why. My guess
> is that the 12/31/1969 date may have been arbitrary, or accidentally
> generated. I don't know, and right now it doesn't really matter to me,
> as I'm entirely on GNUCash, now. Moneydance is a great little checkbook
> program (even despite being 100% Java), but it doesn't fulfill my needs
> as a personal finance manager.
>
> However, I don't see why GNUCash cannot deal with a date like 1969.
> Common Unix philosophy doesn't generally mean that we can't deal with
> dates prior to Jan. 1, 1970, after all! ;)
You didn't read my explanation :) The date recorded internally
wasn't 1969, it was something like 1831, it's just that the time_t
structure couldn't hold a date in seconds that far back and, when
given to the date routines, ended up getting printed as 1969.
GnuCash can handle actual 1969 dates just fine (try it).
This was probably a bug in the qif importer, but there have been
many fixes to the importer since 1.3.7, so the bug may be gone.
If you still have the qif, you might just try it on a blank file
to see if the strange date is still created.
thanks,
dave
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
