ree to choose the sign
of the subtraction result, which means that the spec fails to define
the result of timetz comparison: all that's required is that it be
consistent with your implementation of timetz subtraction. Since we
don't have the latter (and I don't recall anyone asking
On Fri, May 25, 2018 at 3:33 PM, Tom Lane wrote:
> Alexey Bashtanov writes:
> > Comparison of timetz values looks a bit weird to me, as
> > '22:00+02'::timetz > '21:00+01'::timetz.
>
> Perhaps, but I don't think there's a reasonable case for considering
> them equal, either. In the other places
Alexey Bashtanov writes:
> Comparison of timetz values looks a bit weird to me, as
> '22:00+02'::timetz > '21:00+01'::timetz.
Perhaps, but I don't think there's a reasonable case for considering
them equal, either. In the other places where obviously-different
values compare equal, such as zero
Hello,
Comparison of timetz values looks a bit weird to me, as
'22:00+02'::timetz > '21:00+01'::timetz.
I can see this behavior introduced by commit 2792374c in 2001
with the comment "timetz was just plain broken (some possible pairs of
values were neither < nor = nor >)".
The in-code commen
