From: | Francisco Olarte <folarte(at)peoplecall(dot)com> |
---|---|
To: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
Cc: | Chuck Martin <clmartin(at)theombudsman(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Query not producing expected result |
Date: | 2019-05-01 18:04:48 |
Message-ID: | CA+bJJbzPv+Wa1CqhOm8ZtV8ZN6z2=OAF1wR=bB8xm0wXyR9QrA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Adrian:
On Wed, May 1, 2019 at 7:57 PM Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> wrote:
> You will have to explain further as I am not seeing it:
> test_(postgres)# select '2019-05-01 9:52' <= '2019-05-01 24:00'::timestamp;
> ?column?
> ----------
> t
>
> test_(postgres)# select '2019-05-01 24:00' <= '2019-05-01 24:00'::timestamp;
> ?column?
> ----------
> t
Because you are using two selected examples. The one with 9:52 is ok.
The last one is misleading because you are using a constant for a
particular timestamp in MAY THE SECOND wich can be written to look
like it is in MAY THE FIRST.
Rewrite it as
select '2019-05-02'::timestamp <= '2019-05-01 24:00'::timestamp;
And you'll see and out of range date selected.
This is why <= AND 24:00 are bad and misleading.
You may not have problems with 00:00:00 times, but work a bit billing
phone calls and you'll find about one in 86400 hit it ( more in my
case as traffic distribution is skewed ). Use that kind of condition
and you end up chasing why the monthly report has a dozen less calls
than the sum of the daily ones the billing guys made using excel.
Francisco Olarte.
From | Date | Subject | |
---|---|---|---|
Next Message | Francisco Olarte | 2019-05-01 18:09:52 | Re: Query not producing expected result |
Previous Message | Adrian Klaver | 2019-05-01 18:04:44 | Re: Query not producing expected result |