Re: "two time periods with only an endpoint in common do not overlap" ??? - Mailing list pgsql-general

From Francisco Olarte
Subject Re: "two time periods with only an endpoint in common do not overlap" ???
Date
Msg-id CA+bJJbyWKXTa655qaE=xy7ZBf5aWWbQWVKFhnPeMJWif7_yDXQ@mail.gmail.com
Whole thread Raw
In response to Re: "two time periods with only an endpoint in common do not overlap" ???  (Ron <ronljohnsonjr@gmail.com>)
List pgsql-general
Ron:

On Fri, 15 Oct 2021 at 20:16, Ron <ronljohnsonjr@gmail.com> wrote:
> > so no overlap.
> I was afraid you were going to say that.  It's completely bizarre, but seems
> to be a "thing" in computer science.

Right half open intervals are normally choosed because they can fully
cover the real line without overlap. Full open and full closed can
not.

When you have timestamps, or float/doubles, you are trying to
represent a point on a (time) line, although their finite computer
representation is countable.

When you use dates / integers you can use any kind of intervales, as
they are countable, but it is easier if you use the same
representation.

When I do billing I select monthly CDRs in one system on a condicion
on a timestamp column, {setup >= '2021-05-01' and setup<'2021-06-01'}.
Another system as split date/time, and I select on that table using
the same limits, { fecha >= '2021-05-01' and fecha<'2021-06-01' }. I
could use a full closed interval, but half open is easier.

Also, if you cover the countable set of dates with half-open intervals
it has the nice property of having start-range(i)=end_range(i-1),
which is much easier to program.

And half open are easier to generate. If you want to generate 12
element ranges starting at 1 you can do something like

for i=1 to 100 step 12
    print i, i+12

which nicely lets you see they are dozens, if you use closed you need
to "print i, i+11" or "print i, i+12-1".

In general it is a thing because it is easier.

FOS



pgsql-general by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Wrong sorting on docker image
Next
From: Florents Tselai
Date:
Subject: Force re-compression with lz4