No validation on date entry

[Nelson Handcock]

Thanks for the suggestion. I have the "6 months" option set, and entering
31/12 or 31/15 gives me 31/12/2015, and endtering 31/1 gives me 31/1/2016.

It'll probably take a bit of getting used to but I agree it is an
improvement when you have to do lots of data entry.

Thanks again!

Thanks & Regards,

Nelson Handcock
0409 149919

http://www.linkedin.com/in/nelsonhandcockaustralia

On Sun, Feb 21, 2016 at 11:22 AM, Wm <tcnw81 at tarrcity.demon.co.uk> wrote:

> On 20/02/2016 21:55, Nelson Handcock wrote:
>
> > As I work my way through the list of payments (there can be quite a few),
> > I've sometime entered the date incorrectly - simple typo errors.
> >
> > I've noticed in GN that you can enter any kind of value in the payment
> date
> > field, and it will turn it into a nonsensical date and happily save the
> > transaction.
> > For example, if I enter 31/15/15 (DMY format - the month should be 12) -
> GN
> > interprets this as "31/12/1898".
> >
> > The problem I find is that later on (if I haven't noticed the typo), it
> is
> > quite difficult to find and correct the error.
> >
> > So I'm wondering - shouldn't date fields have a basic validation routine
> so
> > that dates that are obviously incorrect be highlighted as an error? I
> think
> > this is similar to amount fields where you should get an error if you try
> > to enter non-numerical data. ie. - the day part has to be between 1 - 31,
> > the month part has to be between 1 - 12.
>
> Try Edit > Preferences > Date/Time then
>   Date format
>   Date completion
>
> The idea is you set it so that it accommodates your  preferred entry
> method.
>
> Going by the above I'd simply not enter the year any more, thus saving
> yourself some keystrokes and simultaneously improving your accuracy.
>
> Using your example above and mangling my ISO dates to dd/mm/yyyy
> entering 31/15 gives me 31/12/2015 which isn't far off if you think
> about it.
>
> --
> Wm
>
>