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: Sun, 07 Aug 2011 13:35:39 -0700

On 2011-08-07, at 12:03 PM, Karsten Hilbert wrote:

> This will most definitely lead to complaints about the
> following behaviour:
> 
> [...]
> 
> Is that the desired behaviour ?

The referenced behaviour is not what I was seeking, it was only my 
(mis)interpretation of what you had written you were going to implement.

All that I know is that I had inputted what (in Canada) should have been 
sufficiently interpretable information, namely

        11/1/1986

which in Canada (locale en_CA) should be sufficient to treat it as 11th day of 
January 1986 however I observed / experienced two problems:

        1) GNUmed did not seem to understand this alternative
                (maybe knowing nothing of locale)
                and treated it as 1st of November 1986

        2) GNUmed did not go to the trouble to provide me with
                updated info (feedback) to understand what
                it had done with the input

Possibly my specific problem was solved by your adding to GNUmed a format that 
can understand and offer dd / mm / (yy)yy

As to what else / more to do with your example

        27.12.1951

which is not an accepted date format but is at least unambiguous (just like 
1951/12-31).

I agree that if the information inputted into the edit area is sufficient to be 
able to generate a valid object to be stored in the backend, it will 
conveniently save the user the extra work to have to "accept" a phrasewheel 
item.

How then would the phrasewheel best be used and understood?

1) if the phrasewheel offers nothing, the user can assume their input has a 
high chance to be inadequate (in which case no date will get stored in the 
backend)?

2) that even before there would be enough raw input for a complete date, the 
phrasewheel may be able to offer one or more suggestions which – *if* selected 
– will replace the raw input by a date that is able to be saved into the backend

3) if the phrasewheel's offerings are rejected, then whether or not a date gets 
successully saved in the backend (and what that date will look like) will 
depend on
(i) whether or not sufficient information was inputted, and
(ii) provided there was sufficient information, whether or not it was ambiguous 
in which case I am not sure whether it might be postgres that decides


-- Jim




reply via email to

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