Heikki Linnakangas wrote:
> Scott Bailey wrote:
>> I would like to add a temporal contrib module.
> I'm very pleased to see people working on temporal issues, BTW!
Me too - common use-case and difficult to handle without the right
types/operators.
>> Nulls - A common use case for periods is for modeling valid time. Often
>> the end point is not known. For instance, you know when an employee has
>> been hired but the termination time typically wouldn't be known ahead of
>> time. We can either represent these with a null end time or with
>> infinity. But I'm not sure how to deal with them. Obviously we can test
>> for containment and overlap. But what about length or set operations?
>
> Hmm. Infinity feels like a better match. The behavior of length and set
> operations falls out of that naturally. For example, length of a period
> with an infinite beginning or end is infinite. For set operations, for
> example the intersection of [123, infinity] and [100, 160] would be
> [123, 160].
There are cases where one time is genuinely unknown, and there we need
a null. For the "until further notice" scenarios, infinity seems the
sensible choice. Where a null is present length is clearly null, and
sets I guess should propagate the nulls. [123,null] intersecting
[100,160] should be [123,null]. That's assuming we've got a guarantee
that from<=to for all periods.
>> Temporal Keys - We need two types of temporal keys. A primary key,
>> exclusion type prevents overlap so someone isn't at two places at the
>> same time.
You're going to upset a lot of managers if they can't do that ;-)
-- Richard Huxton Archonet Ltd
