Re: [Gnumed-devel] Date parsing in Postgres/GNUmed

[Karsten Hilbert]

On Sun, Aug 07, 2011 at 01:35:39PM -0700, Jim Busser 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.

Ah, no, I was sketching out the *consequences* of the
decision "ALWAYS make the user select the date and NEVER
auto-snap" in case you did not think of it. I then asked
whether you'd be prepared to suffer this consequence.

> All that I know is that I had inputted what (in Canada) should have been 
> sufficiently interpretable information, namely
> 
>       11/1/86
> 
> which in Canada (locale en_CA) should be sufficient to treat it as 11th day 
> of January 1986

I agree. The problem was that GNUmed did not yet know of
this being interpretable in more than one way.

> however I observed / experienced two problems:
> 
>       1) GNUmed did not seem to understand this alternative

correct

>               (maybe knowing nothing of locale)

correct, just like now, but this NOT being the cause - it
simply did not know of the alternative per se - it does not
need to know anything of locales in order to be able to know
the useful-to-CA alternative

>               and treated it as 1st of November 1986

indeed, as that was the ONLY interpretation thereof it knew so far

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

Indeed, in some cases that could happen, which is hopefully
improved by now.

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

I should think so and it works just fine here (now).

> As to what else / more to do with your example
> 
>       27.12.1951
> 
> which is not an accepted date format

Wrong. I am glad you fall into the same trap I did,
initially :-)

I did not think to consider 11/1/86 to be interpretable in
more than one way while it perfectly IS: US and CA
understand this to mean something different.

And, of course, 27.12.1951 means the day after Boxing Day in
Germany !

In German we attach "." to numbers to make them ordinals. We
then say: "the 27th 12th 1951" to mean Dec 12th 1951.

See :-)

(and, yes, that works in GNUmed, for me at least)

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

See, and that's exactly what happened with 11/1/86 - GNUmed
found it sufficient to generate a valid object for storage.
The problem was that it was ambiguous - about which GNUmed
knew nothing and thus surprised you by going ahead.

> 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)?

That depends on whether the date is mandatory or optional.

> 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

Indeed, and the dropdown will list the verbose list_labels
of the suggestions.

> which – *if* selected – will replace the raw input

Yes, intended to be in the ISO format YYYY-MM-DD (because
that is re-parseable should the user edit that string
again).

> by a date that is able to be saved into the backend

Again, no, when save is effected it will save to the backend
the *data* (containing a date object) attached to the raw
input). The raw input never makes it to the database.

> 3) if the phrasewheel's offerings are rejected, then
> whether or not a date gets successully saved in the backend

yes

> (and what that date will look like)

no, IF a date is saved in the database it will always be a
date object independent of presentation concerns

> will depend on
>
> (i) whether or not sufficient information was inputted,

yes PLUS whether the date field is optional or mandatory -
if it is mandatory NOTHING AT ALL gets saved

> 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

If it is ambiguous the save needs to be aborted and the user
must be activated to disambiguate.

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346