gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Date parsing in Postgres/GNUmed


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Date parsing in Postgres/GNUmed
Date: Sat, 6 Aug 2011 20:38:59 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Sat, Aug 06, 2011 at 09:30:31AM -0700, Jim Busser wrote:

> Also – in the case of 11/1/86 – the parser in the search handles this as per 
> en_CA and offering me the patient having dob
> 
>       11 January 1986
> 
> while ignoring the patient having dob of 1 November 1986. Yet – when I had 
> created dob
> 
>       11/1/86
> 
> the parser offered only 1986-11-01 (not the alternative of 1986-01-11) and 
> even when I ignored the suggestion of 1986-11-01 because in Canada my string
> 
>       11/1/86
> 
> is supposed to mean 11 January, it did not get saved as 11 January… it got 
> saved as 1986-11-01.

As I said: When the user does not explicitely pick a
candidate but the field NEEDs a data (say, because it is
asked for it by other code, eg a save procedure) then the
field will do its best to produce matches from what's
currently entered. If that produces exactly one match the
field will use that and go ahead. And, of course, the parser
can only generate matches it knows about. Thus fields may
get saved the only way GNUmed knows to parse them (which so
far we've deemed better than not being able to save them).

However, that may be wrong.

The proper technical solution is to NEVER "auto-snap" to the
only match but rather throw an error / force the user the
explicitely select a match.

This will *always* require the user to pick the date from
the picklist even if there's only one match. Fine with me.

We can also keep adding patterns such that we can hope to
always produce several matches when there could be several
and only "auto-snap" when there's truly only one possible
match.

> This seemed to me nothing to do with the parser (or more
> specifically the phrasewheel) because I escaped from it and
> a ttempted to save "exactly" what I had left in the field as

Again, you *can't*.

> GNUmed had in fact saved it as 1986-11-01

Sure, because that's the only thing it knew what that

        "11/1/86"

could mean.

> and had not repainted the screen.

Given the above the question would be: Why would it ?

> So, at minimum, there needs to be a repaint after save of edited identity 
> information

As far as GNUmed is/was concerned everything is unambigous
as is which begs the question - Why repaint ??

> and more ideally the parser could offer
> 
>       1986-11-01 *and*
>       1986-01-11

I added a pattern to that effect - which in turn will
produce both matches and thus prevent auto-snapping and thus
force the user to actively select one match.

> (or could offer the first in the case of en_US and offer
> the second in all other cases) however it would not be
> enough to just offer it, we would need to make sure (given
> the behaviour experienced) that if the user were to select
> 1986-01-11 it would be saved this way :-)

Exactly, Tying input to the locale is bound to identify the
user who both wants a certain locale BUT wants to enter data
another way.

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346



reply via email to

[Prev in Thread] Current Thread [Next in Thread]