[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Date parsing in Postgres/GNUmed
From: |
Jim Busser |
Subject: |
Re: [Gnumed-devel] Date parsing in Postgres/GNUmed |
Date: |
Sat, 06 Aug 2011 09:30:31 -0700 |
On 2011-08-06, at 7:56 AM, Jim Busser wrote:
> Updated
>
>
> http://wiki.gnumed.de/bin/view/Gnumed/GmManualGuiElements#The_Date_Timestamp_field
What the user experiences *inputting* dates is slightly different when they are
trying to (search) a date in the patient search box.
Taking the examples of patients with dates of birth of
11 Jan 1986
13 Sep 1953
a search on the long ANSI form seems will reliably work:
1986.1.11
1953-9-13
whereas the following works for the first dob but *not* the second (which needs
yyyy) which is curious because the second is even less ambiguous:
11/1/86 works
11.1.86 works
13.9.53 fails
13-9-53 fails
*************************************************************
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.
This seemed to me nothing to do with the parser (or more specifically the
phrasewheel) because I escaped from it and attempted to save "exactly" what I
had left in the field as
11/1/1986
and clicked "Save". While what remained continued to *look* correct to me in
Canada as
dd/mm/yyyy
GNUmed had in fact saved it as 1986-11-01 and had not repainted the screen.
After I set focus on a different patient and then came back, I saw
unambiguously that it had been saved as 1986-11-01.
So, at minimum, there needs to be a repaint after save of edited identity
information and more ideally the parser could offer
1986-11-01 *and*
1986-01-11
(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 :-)
-- Jim
- Re: [Gnumed-devel] Date parsing in Postgres/GNUmed, Karsten Hilbert, 2011/08/06
- Re: [Gnumed-devel] Date parsing in Postgres/GNUmed, Jim Busser, 2011/08/06
- Re: [Gnumed-devel] Date parsing in Postgres/GNUmed, Karsten Hilbert, 2011/08/06
- Re: [Gnumed-devel] Date parsing in Postgres/GNUmed,
Jim Busser <=
- Re: [Gnumed-devel] Date parsing in Postgres/GNUmed, Karsten Hilbert, 2011/08/06
- Re: [Gnumed-devel] Date parsing in Postgres/GNUmed, Jim Busser, 2011/08/06
- Re: [Gnumed-devel] Date parsing in Postgres/GNUmed, Karsten Hilbert, 2011/08/06
- Re: [Gnumed-devel] Date parsing in Postgres/GNUmed, Jim Busser, 2011/08/06
- Re: [Gnumed-devel] Date parsing in Postgres/GNUmed, Karsten Hilbert, 2011/08/07
- Re: [Gnumed-devel] Date parsing in Postgres/GNUmed, Jim Busser, 2011/08/07
- Re: [Gnumed-devel] Date parsing in Postgres/GNUmed, Karsten Hilbert, 2011/08/07
- Re: [Gnumed-devel] Date parsing in Postgres/GNUmed, Jim Busser, 2011/08/07
- Re: [Gnumed-devel] Date parsing in Postgres/GNUmed, Karsten Hilbert, 2011/08/07
- Re: [Gnumed-devel] Date parsing in Postgres/GNUmed, Jim Busser, 2011/08/08