Folks,
Wow. Talk about asking dangerous questions ...
> For a 3-part (month/day/second) interval, I think the preferable rule
> for timestamp subtraction is to use the largest symbolic component
> possible, ie, use the largest number of months/years you can, then
> use the largest number of days fitting in the remainder, then express
> what's left as seconds. This is an arbitrary choice among the many
> possible 3-part representations of a given interval, but it seems
> like
> the most natural one for many applications.
Sure, that makes sense. In the meantime, I'll add a note to the FAQ
which says "Adding and subtracting wildly disparate time values (e.g. '1
year'::INTERVAL - '3 seconds'::INTERVAL) may cause the database to make
unusual interval value choices which could impair accuracy. Please test
extensively before relying on operations of this sort."
> Isn't it? The relationship between years, days, and seconds is
> *inherently* context dependent in the common calendar. It might not
> be
> too sensible, but sensibleness has never held sway in calendars, at
> least not since the Romans.
Peter is absolutely correct here. '1 year'::INTERVAL - '1
day'::INTERVAL is '364 days'::INTERVAL most of the time. However, on
leap years it is '365 days'.
> I'm not sure your notion of fractional months really holds water,
> at least not for this particular operation. When is 25 Feb 2000
> plus 0.95 month? Is the 0.95 measured with respect to the length
> of February, or of March? Does it matter that 2000 is a leap year?
> There may be some other operations that have sensible interpretations
> for such a datatype, however.
One way to simplify this would be not to allow any division operations
on INTERVALS that result in a modulo of a smaller increment than the
INTERVAL value expressed. Thus, one could "'3 months'::INTERVAL / 3"
but would not be allowed to "'2 months::INTERVAL / 3". However, this
seems kind of unfair to hour, minute, and second values whose fractions
are well-defined and easily manipulated.
Or, to put it another way, 95% of the time users just want to do simple
things. Like we want to know how many weeks an employee has been with
us for: '2 years 3 months'::INTERVAL / '1 week'::INTERVAL (and we
don't care about the fractional week left over).
Thus we don't want to hold up simple and obvious date multiplication and
division just to deal with the wierdo cases.
-Josh Berkus
______AGLIO DATABASE SOLUTIONS___________________________
Josh Berkus
Complete information technology josh@agliodbs.com
and data management solutions (415) 565-7293
for law firms, small businesses fax 621-2533
and non-profit organizations. San Francisco
