...
> Specs are a good thing and should be adhered to. We should not however
> blindly follow them off a cliff.
Right.
> If a function can not be implemented that both
> follows the spec and gives the right answer then IMHO the function should
> not be implemented. At least this way the user knows he/she has to implement
> thier own. The way it stands the result is the programmers worst enemy, the
> silent error. However, by my reading of the spec, it is silent on the
> correct implementation of overlap for TIME data and therefore we should be
> free to do the right thing.
Hmm. We are discussing this so that all viewpoints and interpretations
are uncovered. But afaict the spec is very clear on this by the fact
that it does *not* call for exceptions or differences in the
implementation for the "datetime data types". And in the spec it does
not specify only TIMESTAMP variants for use in OVERLAPS. If the spec
calls for a particular behavior (which it seems to in this case) then
*someone* is going to be disappointed here; either you because it does
not do what you want or someone else who knows the spec and finds that
it does not do what they expect.
Extra pairs of eyes are helpful here; can anyone see that TIME is
excluded from the types defined for OVERLAPS (which would free us to Do
It Our Way) or if the spec calls for an implementation different from
the part of the spec I found (which might be The Right Way)?
If we end up agreeing as a group on what the spec calls for, and if it
turns out that it doesn't call for a wrapping behavior on time
boundaries, then you *could* fix this with your own function which
checks for wrapping behavior and acts accordingly.
We could also implement a separate function for time types which Does
The Right Thing.
- Thomas
