The problem with making all dates into ranges is that there would be no total order. To effectively have a total order, you would need to say "give me the range of time at the smallest possible granularity", which is really just asking for a point in time. If the granularity becomes smaller later, it might break the application if you aren't careful. So, I don't think it's a good idea to give up on points in time.
However, I strongly agree that ranges of time are a very useful concept, and I spent a lot of time implementing Range Types[1] in postgresql for that reason. I think Ruby should have both ranges of time and points of time (and ideally work with the SQL counterparts seamlessly).
Does a point in time ever really exist? I think it's all ranges, just with smaller granularities, until you get into quantum mechanics. So, your point-in-time type is actually a range-with-granularity-X type, which should be able to inter-operate with range types of different granularities in a well-defined way.
I've recently done a lot of work using time ranges (a scheduling app) in C#, using the TimePeriod library available via NuGet. Very helpful library, but it would have been even better if DB2 (which I have to use quite often) supported a range type like you've implemented for PostgreSQL.
I agree, but that gets a little too philosophical. Does an integer exist? What about characters: is my "a" really the same as your "a"?
The way I see it, there are a lot of practical reasons to look at time as a total order for some things, even if ranges are available. Programming languages and databases should model reality, but only in the sense that it's relevant to what you are trying to do. If you are writing a scheduling app, then ranges of time are very important, and should be their own data type. If you just want to tell your customers when they bought some widget, a point in time makes more sense.
Of course an integer exists; it's a mathematical zero-dimensional point. Time is not a pure mathematical construct like that; it's continuous (at non-quantum scales, at least). Characters are integral, non-continuous values too... there's nothing between "a" and "b".
If you define the total order of a set of time ranges as an ordering on their beginnings, then you have the ordering you're talking about. If you compare time ranges that have different granularities the results might not make a ton of sense depending on what you're trying to do, but they'll be consistent. Eg: 2012 < 2012-05 < 2012-05-03 < 2012-05-03T15:00:00. Is the year 2012 "less than" May 3, 2012? Interpreted as a point in time, yes, but interpreted as time periods no, not really, because they overlap. But 2012 might be a perfectly valid value for when a customer bought some widget; if you ask them they may not remember the date any more specifically than that, and if you're deciding whether or not to process a warranty claim just knowing the year might be sufficient.
"If you define the total order of a set of time ranges as an ordering on their beginnings"
What is the data type of the beginning of a range of time, if not a point in time? I'm having trouble even defining ranges without points.
I'd be interested to hear your suggestions in more detail. There's a temporal data LinkedIn group that you are welcome to join (I haven't been as active lately, but I'll try to get back into it). It would be a better forum to discuss matters like this.
