[Top][All Lists]
[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