One date is not the other in a domain or database model. Registering a birthdate is probably fine. But as soon as we start to register date's as intervals everything becomes complicated.
To update someone's adress in a typical datamodel would require a single SQL statement. However if we want to register the history we would require two statements. One statement to register the enddate of the old adress, and one to register the new adres.
However if in this case we need to change the history, then it becomes more complicated. It may take 12 to 14 statements to handle all special cases such as truncating overlaps. If this code is intermixing with regular domain logic, which is also complex then there may be no end to trouble.
This is a serious risk for a project. One programmer writes it, several weeks later someone else is going to try to fix it, and introduces new bugs just because of the complexity.
Mixing domain logic with temporal logic is definitely an antipattern. I call it the Chronos anti-pattern. And many project have fallen premature victim to father time because of temporal logic.
We are going to seek solutions for this problem in the chronos4j project.
(source: wikipedia) See also Father Time in the wikipedia.