[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Date parsing in Postgres/GNUmed
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-devel] Date parsing in Postgres/GNUmed |
Date: |
Sun, 7 Aug 2011 23:14:40 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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
- Re: [Gnumed-devel] Date parsing in Postgres/GNUmed, (continued)
- Re: [Gnumed-devel] Date parsing in Postgres/GNUmed, Karsten Hilbert, 2011/08/06
- Re: [Gnumed-devel] Date parsing in Postgres/GNUmed, Jim Busser, 2011/08/06
- Re: [Gnumed-devel] Date parsing in Postgres/GNUmed, Karsten Hilbert, 2011/08/06
- Re: [Gnumed-devel] Date parsing in Postgres/GNUmed, Jim Busser, 2011/08/06
- Re: [Gnumed-devel] Date parsing in Postgres/GNUmed, Karsten Hilbert, 2011/08/06
- Re: [Gnumed-devel] Date parsing in Postgres/GNUmed, Jim Busser, 2011/08/06
- Re: [Gnumed-devel] Date parsing in Postgres/GNUmed, Karsten Hilbert, 2011/08/07
- Re: [Gnumed-devel] Date parsing in Postgres/GNUmed, Jim Busser, 2011/08/07
- Re: [Gnumed-devel] Date parsing in Postgres/GNUmed, Karsten Hilbert, 2011/08/07
- Re: [Gnumed-devel] Date parsing in Postgres/GNUmed, Jim Busser, 2011/08/07
- Re: [Gnumed-devel] Date parsing in Postgres/GNUmed,
Karsten Hilbert <=
- Re: [Gnumed-devel] Date parsing in Postgres/GNUmed, Jim Busser, 2011/08/08
- Re: [Gnumed-devel] Date parsing in Postgres/GNUmed, Karsten Hilbert, 2011/08/08
- Re: [Gnumed-devel] Date parsing in Postgres/GNUmed, Karsten Hilbert, 2011/08/08