gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] [Gnumed-bugs] Minor bug in Demographics plugin - need


From: Jim Busser
Subject: Re: [Gnumed-devel] [Gnumed-bugs] Minor bug in Demographics plugin - needs refresh of Identity pane (upper left) on updating
Date: Fri, 29 Jul 2011 18:34:08 -0700

On 2011-07-29, at 5:51 PM, Jim Busser wrote:

> Here is the thing… if we say or understand the '-' to be reserved as always 
> treated as [yy]yy-mm-dd and if instead I use a different separator '/' and 
> input the same string with '/' as
> 
>       12/8/1984
> 
> then Postgres/GNUmed recognizes the 1984 as the year but goes on to make a 
> *different* mistake, because it then applies the American interpretation as
> 
>       Dec 8 1984
> 
> despite my locale is en_CA and it should have been interpreted into 12 Aug 
> 1984.

OK I think I have figured this out and it may require only clearer 
user-community understanding of how Postgres/GNUmed handles dates…

The following seems to apply (at least) to locale = en_CA and might apply to 
other locales as well, I would be interested if people in other locales could 
play with the

        Demographics plugin

                Identity tab

                        'Born' field

and see and report whether the same applies. At least for en_CA (which is 
supposed to be dd/mm/yyyy ) the separator makes a difference, where

        /       forces American
        .       correctly handles the input
        -       forces treatment as yy-mm-dd (or yyyy-mm-dd if compatibly 
entered)

therefore in trying to enter a Canadian date of birth of

        12 August 1984

if in Canada (en_CA) you input the following --> what you get is…

        12/8/1984       -->     1984-12-08 wrong


        12.8.1984       -->     1984-08-12 correct
        12.8.84         -->     1984-08-12 correct (but only because the 
patient is below age 70, see below)


        12-8-1984       -->     2012-08-19 wrong (and even puts the dob into 
the future)
        12-8-84         -->     this gets rejected and will not save,  since 
2012-08- cannot accept a 'day' of 84


****************************
Year of birth and century *
****************************

If the patient year of birth is within 69 of current (e.g. relative to 2011, 
born in 1942 or later)

        then a two-year yy (instead of yyyy) is correctly interpreted as 19yy

BUT if the difference is 70 years or more, then the wrong century risks to be 
applied. Therefore if on July 30, 2011 you input the following two-digit years 
of birth, what you get is

        30.7.42         -->     1942-07-30

        31.1.41         -->     2041-01-31

… in case anyone would reply with any more observations, I will hold off before 
recommending tooltip improvements :-)

-- Jim

        


reply via email to

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