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

[Karsten Hilbert]

On Sat, Aug 24, 2013 at 03:04:38PM +0000, Jim Busser wrote:

> Karsten's primacy in developing, maintaining and releasing "GNUmed main" make 
> it sensible to defer -- until he expresses having better interest/time -- 
> those items are desirable to gain his participation.
> 
> Accordingly I will hold off a side-discussion that I had opened with someone 
> from postgres from whom I had asked some help around this uncertain date-time.

Recognizing the possibility of this approach was what made
me say "I would accept patches which show sufficient
coverage of the problem" along with "I don't need to fully
understand every detail of the implementation myself if
there was knowledgeable 4th party review" (say, PostgreSQL
community). I also outlined to stack which needs to be
supported: PostgreSQL, psycopg2, python, wxPython, GNUmed.
Assuming a data type had been written with adequate support
for PostgreSQL and someone took care of psycopg2 support I'd
be willing to invest in the other half of the equation. I am
not sure I am equipped to do the PG part myself, less unsure
about the psycopg2 part.

> Their preliminary thoughts had included:
> 
> - that custom data types are not difficult
> 
> - however, what we would be talking about would not be a date or timestamp, 
> as these are basically stored as seconds from epoch
> 
> - off the top of their head, it would be a string type with special rules

That would at least be one possible approach. The other
approach would be a custom type comprising a standard
timestamptz combined with a smallint holding the accuracy.
Something similar exists for values-with-units.

My approach in comparing that to a standard timestamptz
would be to create a copy of the other timestamptz and set
those values which are not known to the same as in the
accuracy-restricted timestamptz. That way one can simply
apply the standard comparison operations. In computations
the result would be a accuracy-restricted timestamptz with
the same accuracy as the one of lower accuracy.

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