Re: [Gnumed-devel] restrictions vs. conventions (uncertain date-time)

[Jerzy Luszawski]

On 24-08-2013 12:26 Karsten Hilbert <address@hidden> wrote:


> > 2. if the date has day or day and month as 01 or Jan-01 respectively,
> > this part of date is unknown, unless non-zero hours are entered (the
> > hours part is ignored in any case, but entering non-zero value means
> > that Jan-01 date is exact)
> 
> While a good idea - the columns in question being timestamps
> they cannot have invalid (did you mean invalid ?) hours. In
> case you did mean valid-but-numerically-zero hours then,
> yes, that may work as a convention for many people and it is
> a practical idea again. 
I meant 00:00:00 hours as a default when typing in date.

> For me, personally, it wouldn't
> because I regularly work 24h shifts meaning I regularly
> prescribe (and thus start people on - at least as far as
> GNUmed is concerned) drugs in the wee hours of the morning
> or even just after midnight.
I see no problem: if you prescribe something the date is known, it can
be inserted automatically (as now()) and it will mostly have non-zero
hours or minutes and will be interpreted as exact date, which is true
and desired. Of course you must be careful on the very second when
midnight on the 1st day of month passes - but seriously - how important
is this case really?
If you type in eg. 2013-05-01 *without* hours:minutes it will be
interpreted as "some day in May, 2013". If you manually enter such a
date and add some non-zero hours:minutes, imposed by your *convention*,
let's say 2013-05-01 11:11:11, it will be marked as exact date. The
hours:minutes:seconds part is unimportant anyway, as you described
below.
But the details are not important and may easily be customized for
selected users in GUI, for example if someone adopts the above
described convention and mostly enters exact dates, the default time
when only date is entered can be set to non-zero (00:00:01 or
anything), and user can erase it to mark uncertain date.

Generally such a convention makes is possible to use *existing
program*, *immediately* in 29 of 30 cases (= days of month), with
minimal costs of your attention during one day in month. 
 
> 
> HOWEVER, taking a step back and looking at the big picture
> two things come to mind:
> 
> Does it even matter whether what time of day a drug was
> started ?  For most people it won't so the time part can get
> used for storing other things (yes that IS MIGHTY UGLY).
Exactly, that's why it can be marker of accuracy. Even if you know the
exact second of the prescription, it is not valuable for further
analysis.

> Also, in case a drug had been started within the last, say,
> 2 months or so (to be agreed on) it may actually matter
> which exact day as to be able to find out whether a
> guidelines recommended duration has been reached.
(...)
> In cases a drug has been taken for many years it doesn't
> matter in the least which day or even month it started.
> 
> So, why not teach GNUmed this morsel of clinical knowledge ? 
> This is AFAICT what Jerzy hints at with "client side
> handling".
Yes. The useful presentation of time intervals can be different,
depending on how big this interval is. But I personally prefer the
start date to be displayed as well (hence the added column 'registered'
to waiting list plugin :)

> Nonetheless, having a datatype "timestamptz with given
> accuracy" supported along the entire stack of PostgreSQL,
> psycopg2, Python, wxPython and GNUmed would be much
> desirable.
Maybe, but how would you enter such a value?
Eh, I don't have time for discussion on implementing new data type, as I
will not work on it. Sorry. Let's drop it for now.

-- 
Pozdrawiam,
Jerzy Luszawski