Re: [Gramps-devel] Malformed dates are useless

[Brian M. <br...@gr...>]

Doug,

> I was wrestling with what I though was a bug for far
> too long when I
> finally realized that the date on the event was
> malformed in a subtle way
> (in this instance it was "12-04-1982", but I suspect
> that there may be
> lots of ways for dates to be subtly wrong). Oh,
> another one: "Jan 5, 1863
> or 1864".
> 
> Of course, if you have just a slightly malformed
> date, it isn't a date at
> all, and is almost useless. Ok, you can do a search
> and find a textual
> match. But it isn't a date: won't sort right, can't
> be used in date
> computations (ages), time lines, etc.
> 
> Unfortunately, GRAMPS doesn't do a very good job of
> indicating that this
> is a malformed date, except on the data entry
> screen, where it turns red
> and shows a stop sign. Good, but unless you go to
> that screen, the bad
> text won't be obvious. In fact, if you import the
> data, you might never
> know.
> 
> So, I wanted to indicate these malformed dates on
> the main tables, People
> View, and the event lists. But how to mark it? I
> tried various text: [*],
> err:, Invalid:, but nothing seemed to work as well
> as doing part of what
> the data entry form does: make the background
> reddish.
> 
> So, check out trunk revision 10597. I think the
> color blind will be able
> to see that those cells are different, and it
> doesn't have a speed impact
> on the People View as those cells are already doing
> markup. But it does
> help quite a bit in seeing malformed dates.

The problem is valid. I haven't looked at your
implementation. I have no strong opinion except to say
that I hope it doesn't overly complicate the code.

Have you considered adding a check for invalid dates
to the "Verify the database" tool? It seems to me that
might be appropriate.

~Brian