On Tue, 2009-12-15 at 18:03 -0600, decibel wrote:
> I think it would help the discussion if you could provide some real
> examples. I suspect you're thinking of things like scheduling apps,
> where it's important to be able to do things like "what's the next
> available time slot?". There are probably ways to make that kind of
> thing easier without resorting to discrete time.
I did provide some examples:
http://archives.postgresql.org/pgsql-hackers/2009-12/msg01385.php
I think the bottom line is that we can't expect all applications to
understand all 4 inclusivity permutations. Think about how many
applications you've seen with "start" and "end" entry boxes, and you
have to pick up from the surrounding words what inclusivity it's
expecting. If you're running two such applications at once and they
share data (perhaps an entry app and a reporting app), or you're
migrating from one to another, you have a problem if you can't convert
the intervals to the expected format.
I don't see it as "resorting to discrete time". I view discrete
intervals as simpler in many ways: there exists a canonical inclusivity
representation, and you can take that canonical representation and
display it however you want.
We should at least allow the user to specify that their range is
discrete (even if only by a superuser). And the user should also be able
to specify that they don't want null boundaries or extra infinity
boundaries, so that they get back down to the 16-byte representation.
> I find myself wondering if they were influenced by the technology
> available at the time...
No, it's entirely at the logical level. It's also not a very old book
(2002).
For another author that apparently likes to deal with discrete time, how
about "Developing Time-Oriented Database Applications in SQL" by
Snodgrass. It's free to download online, I believe.
Regards,Jeff Davis