On Fri, May 25, 2018 at 3:33 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alexey Bashtanov <bashtanov@imap.cc> 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 versus minus zero in IEEE floats, it's widely understood as a gotcha.
Except all we've done here is expose an implementation detail since timestamptz compares on a logical "point in time" notion of equality while timetz does not. Limitations of timetz aside adding a random date and changing the type to "timestamptz" would not obviously cause the result of the above comparison to change and the fact that it does could be considered a gotcha when the behavior of timestamptz is likely to be the widely understood and accepted and the behavior of timetz inferred from it.
> What's the problem with these values to be considered equal? > Backward compatibility? Hash algorithms?
Even if you'd made a case why we should consider them equal, those would be very good reasons not to change behavior that's stood for 17 years.
This is true, and the alternative doesn't have the supporting argument of being spec-compliant either...
The notes in 8.5.3 Time Zone (v10 docs) seem to apply here overall - the type, while standard, is ill-conceived. Those who cannot stop using it would not appreciate us changing it and those dealing with the oddity now should just use timestamptz.
