gnumed-bugs
[Top][All Lists]
Advanced

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

Re: [Gnumed-bugs] Minor bug in Demographics plugin - needs refresh of Id


From: Karsten Hilbert
Subject: Re: [Gnumed-bugs] Minor bug in Demographics plugin - needs refresh of Identity pane (upper left) on updating
Date: Wed, 3 Aug 2011 17:26:25 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Sat, Jul 30, 2011 at 01:37:32AM -0700, Jim Busser wrote:

> > Parsing 12/8/1984 as Dec 8 1984 is both formally correct and making
> > a lot of sense to a lot of people.
> 
> No, this only makes sense to Americans or people familiar with the American 
> format.

Well, that *is* a lot of people (not that I care that much,
however ;-)

> You are (I think) talking about how GNUmed (in the dropdown menu) offers
> 
>       1984-12-08
> 
> however even if I do not select it, but instead leave my input as
> 
>       12/8/1984
> 
> the above seems to be stored in that form

That's the second bit of the problem: Since 12/8/1984 IS
parseable and you did not select anything *else* (including
another possible, equally correct, parsing of that string)
GNUmed goes ahead and does use that parse result. So far we
did take a bit of care in that we ONLY went ahead and
auto-used the parse result without the user explicitely
selecting it when there was only one possible (as known to
GNUmed !) result. That's the problem: While GNUmed may not
know about other, equally correct, possible parse results
such may still exist and be desired by the user. Hence I
suggested we refrain from auto-using parse results AT ALL
thereby forcing the user to ALWAYS select from the dropdown
list. That would, at least, make it unambigous. What do you
think ?

BTW, the current date input phrasewheel offers much better
parse result list labels and also a much improved tooltip
showing an unambigous version of the date typed or selected.

> Basically it seems that it is the separators (combined with
> whether or not a 4-digit year has been entered) that
> determines how Postgres / GNUmed interpret date entry.

Sort of. Not really. Rather, it is only incidental to the
actual implementation.

> It is not clear to me that LC_ALL or LC_TIME make any
> difference.

Not that GNUmed ever claimed any such thing AFAICR.

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

Attachment: screenshot_001.png
Description: PNG image

Attachment: screenshot_002.png
Description: PNG image


reply via email to

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