Time span conversion function
I've got an idea for a new internal function. I'm more than willing to
code it myself, but I'd like to run it past the list and thrash out any
conceptual issues before I get too excited about writing a patch.
When dealing with time values, it's not unknown to want to see a
particular time span (not the same as a postgres "interval", see below)
expressed in one particular time unit. You might want to know how many
months have passed since a certain date, or how many minutes between two
events. Postgres doesn't really have any functions to help out with
this. You can always develop workarounds to get the result, but IMO
this would be more elegantly dealt with internally.
My proposed function, let's call it time_span for now, would take a unit
of time as text (like date_part does), and two delimiting timestamps (or
a timestamp and an interval). The result would be the time span
converted into the specified unit. So for example:
SELECT time_span( 'month', '2004-10-01', '2005-02-22' );
4
SELECT time_span( 'minute', now(), interval '10:43:55' );
643
It may seem strange at first to be using two timestamps instead of a
single interval value, but there's a reason for it. A postgres interval
is just a "delta". It does not refer to any point in time, only
separate quantities of the various units. Therefore it is impossible to
convert between units that don't have consistent relationships (being
day <=> month and day <=> year) without approximating. By using two
real timestamps, you can accurately convert the span into any of the
available units.
You could make the function even more powerful by adding an optional
fourth "precision" argument, which when given allows the function to
return a fractional part. Like so:
SELECT time_span( 'month', '2004-10-01', '2005-02-22', 2 );
4.79
SELECT time_span( 'minute', now(), interval '10:43:55', 4 );
643.9167
That about does it for my initial proposal. Fire at will.
BJ
On Sat, 15 Jan 2005, Brendan Jurd wrote:
SELECT time_span( 'minute', now(), interval '10:43:55' );
643
The timestamp argument to this version of the function seems completely
irrelevent.
Kris Jurka
Kris Jurka wrote:
On Sat, 15 Jan 2005, Brendan Jurd wrote:
SELECT time_span( 'minute', now(), interval '10:43:55' );
643
The timestamp argument to this version of the function seems completely
irrelevent.Kris Jurka
I don't think so. As I pointed out in the OP, to make this function
work properly you need to define a startpoint and an endpoint. The
version of the function which accepts (text, timestamp, interval)
arguments is really just using another notation to achieve the same
thing - startpoint and endpoint.
The timestamp argument is only irrelevant if you're willing to assume
now() is going to be the startpoint, which is not a fair assumption
IMO. I would rather give the caller the freedom of defining the
startpoint himself, in either notation.
Of course, it would be possible to create a shorthand version of the
function which expects (text, interval), and passes directly to
time_span($1, now(), $2).
Does that resolve your concern? If not please explain it more fully.
BJ
Brendan Jurd <blakjak@blakjak.sytes.net> writes:
Of course, it would be possible to create a shorthand version of the
function which expects (text, interval), and passes directly to
time_span($1, now(), $2).
This bothers me a bit. That essentially says that (text, interval)
has a hidden instability: the results depend on when you execute it.
If we allow this form, it should be restricted to only those units
(values of the text parameter) for which the result would *not*
depend on now().
regards, tom lane
Tom Lane wrote:
Brendan Jurd <blakjak@blakjak.sytes.net> writes:
Of course, it would be possible to create a shorthand version of the
function which expects (text, interval), and passes directly to
time_span($1, now(), $2).This bothers me a bit. That essentially says that (text, interval)
has a hidden instability: the results depend on when you execute it.If we allow this form, it should be restricted to only those units
(values of the text parameter) for which the result would *not*
depend on now().
mm, I see your point. I suppose the only real reason to have the
shorthand version is for people who want to test an interval value and
don't particularly care what the startpoint is -- so they just use now()
because it's a convenient way of getting a timestamp that satisfies the
function.
To be honest, I'd be quite comfortable with dropping the shorthand
version from the proposal. If the caller has to type another 7
characters, so be it. It could fall under the "if you want it, define
your own function for it" category.
BJ