Re: Timetz comparison

Поиск
Список
Период
Сортировка
От David G. Johnston
Тема Re: Timetz comparison
Дата
Msg-id CAKFQuwbdZFUps_WrW-N=WDD7=PG8i08Xx7ioeyar=Ly3g=+kCg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Timetz comparison  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Timetz comparison  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Дерево обсуждения
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.

https://www.postgresql.org/docs/10/static/datatype-datetime.html

David J.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Chapman Flack
Дата:
Сообщение: Re: SPI/backend equivalent of extended-query Describe(statement)?
Следующее
От: Tom Lane
Дата:
Сообщение: Re: SPI/backend equivalent of extended-query Describe(statement)?