On Fri, May 25, 2018 at 3:33 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Alexey Bashtanov <bashta...@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. https://www.postgresql.org/docs/10/static/datatype-datetime.html David J.
