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: Jim Busser
Subject: Re: [Gnumed-bugs] Minor bug in Demographics plugin - needs refresh of Identity pane (upper left) on updating
Date: Sat, 30 Jul 2011 01:37:32 -0700

On 2011-07-29, at 6:25 PM, Karsten Hilbert wrote:

> GNUmed does not make a different mistake. It parses the date just fine
> as something that that string could mean.
> 
>> despite my locale is en_CA and it should have been interpreted into
>> 12 Aug 1984.
> 
> GNUmed never made any such claim hence it's a shortcoming but
> certainly not a bug.
> 
> 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.

Also, I was insufficiently clear.

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 until I move off the patient and come 
back, at which point it is clear that without any confirmation on my part, one 
of Postgres or GNUmed have gone ahead and resolved

        12/8/1984

to mean

        1984-12-08

and nothing else. 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. It is not clear to me that LC_ALL or LC_TIME make 
any difference.

See my post of a half hour ago on devel

        Date parsing in Postgres/GNUmed

        http://lists.gnu.org/archive/html/gnumed-devel/2011-07/msg00285.html

-- Jim


reply via email to

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