Slightly smarter date parsing?

[Manfred Usselmann]

On Mon, 8 Jan 2007 08:26:40 -0800
Andrew Sackville-West <ajswest at mindspring.com> wrote:

> On Sun, Jan 07, 2007 at 03:09:34PM -0800, Thomas Bushnell BSG wrote:
> > On Sun, 2007-01-07 at 15:16 -0600, Jamuraa wrote:
> > > I was putting my receipts in for the last half month or so recently
> > > and noticed that I had to be careful to notice the year that the
> > > receipts were in.  When putting in 12/23 or similar, I didn't get
> > > December 23, 2006, but December 23, 2007.  I thought this should be
> > > different, so I dove into the gnucash code and changed qof_scan_date
> > > slightly to choose the last year for December if the current month is
> > > January.  The patch is attached.
> > 
> > This behavior has also always annoyed me.
> 
> me too! but it only crops up once a year. How long after 1/1 are
> people still entering 12/xx items? Granted, I routinely enter 50+
> items from the previous month, so its been particularly annoying. But
> I think, in terms of gnucash doing exactly what is expected, entering
> 12/31 and getting 12/31/07 makes sense. It is totally predictable in
> all cases that the year *will* be the curent year. Anything else would
> introduce uncertainty in its behavior and that's probably bad IMO. 

It has also annoyed me several times, but I also agree that the
program should behave predictable and not guess something. 

Since I often enter data for the same accounting period and assume a
lot of people do, my suggestion is to use the date from the last
entered / changed transaction to complete an partial entered date:

 - If only the day is entered, use last entered month and year.
 - If only day and month entered, use last entered year.
 - Where there is no previous data (first transaction after
   program startup), use current month and year.

The advantage of this would be that it would also work for the future
or more than one year backwards and it would alwasys keep me within the
date period I'm working on. But the inital default would always be the
current month even at the beginning of a new year. As soon as I switch
to a different period the program switches to that period as well.

This logic would even be useful during the current year. Let's assume
I've been a bit lazy for a while and want to catch up with my bookings
and have to start some months ago. As soon as I've entered one
transaction for the first month I only need to enter the day since that
month will be the default. For the first transaction of the following
month I enter day and month and then again only the day. And so on...

Manfred