[Gnumed-devel] Date parsing in Postgres/GNUmed

[Jim Busser]

renamed from:

Re: [Gnumed-devel] [Gnumed-bugs] Minor bug in Demographics plugin - needs 
refresh of Identity pane (upper left) on updating

On 2011-07-29, at 7:08 PM, Karsten Hilbert wrote:

>> … in case anyone would reply with any more observations, I will hold off
>> before recommending tooltip improvements :-)
> 
> Tooltip improvements require little work code-wise so go ahead.


The following seems (after some testing) to be accurate:

        -       forces processing as (yy)yy-mm-dd
        /       forces processing as mm-dd-yy(yy)
        .       accepts yyyy.mm.dd, otherwise treats the end-portion as year

        historical dates within the past 70 years do not require yyyy

*****************************************************************

I tested the above after I read

http://www.w3.org/International/questions/qa-date-format

> The format MM/DD/YY is unique to the United States. Most of Europe uses 
> DD/MM/YY. Japan uses YY/MM/DD. The separators may be slashes, dashes or 
> periods. Some locales print leading zeroes, others suppress them. If a native 
> Japanese speaker is reading a US English web page from a web site in Germany 
> that contains the date 03/04/02 how do they interpret it?

after which I did the following:

        #exited GNUmed
        # stopped postgres server, using binaries from Enterprise DB 
/Applications/PostgreSQL\ 8.4

        #set locale to Japanese
        export LC_ALL=ja_JP.UTF-8

        #observe the effect
        locale LC_TIME

        #restart postgres server

        #load GNUmed
        #try inputting valid Japanese date in official format yy mm dd (using 
official / )

                84/8/12 --> rejected since the slash treats 84 as invalid, 
assuming mm dd yy

        #but sane values if assumed to be in "American" format mm dd yy are 
accepted:

                8/12/84 --> success

        #also I verified that this was not a problem of failure of the locale 
to remain japanese:
        env | grep LC

        #which returns
        LC_ALL=ja_JP.UTF-8 

therefore the separator / seems to force American-style mm dd yy irrespective 
of the locale. The hyphen is always safe when the first two (or four) digits 
are intended to be interpreted as years, so in Japanese

        84-8-12 --> 1984-08-12

The dot is trickier. It will always process smartly when either the first 
triplet or last triplet consists of 4-characters. When only 2 digits are 
supplied, it expects the year in the final triplet, and so

        84.8.12 --> gets refused

        #  but you input the full century:
        1984.8.12       --> it is accepted
        
-- Jim