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: 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


reply via email to

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