Domain logic can be complicated. For example labour and compensation rules can be complicated. Do you get paid when you are sick, and what if you are sick with christmas and not working anyway? So is timeline logic. You have to deal with various intervals which may be out of synch, and determine a solution.
Intermixing timeline interval logic with complicated business logic creates tremendous complexity. To update an address would typically be a single SQL statement. If we want to keep history of where a person has lived, an we need to make a retrospective correction then about 12 to 14 SQL statements are needed to handle possible combinations of overlapping and abutting intervals. And this is not "just" 14 times as much logic, but much more. Try it if you donot believe this.
If the project is budgetted with a function point analysis then there is just one maybe two extra fields. This is not gonna give you lets say twice as much function points.
And if we leave this to some poor soul to program it out it will typically not work. Fixes wil introduce new errors and there is no end to trouble.
Separate interval and timeline logic.
The Java library has a Calendar type implemented in a GregorianCalendar. The debate if we would be better of with a value object is something we leave to the Joda-Time project.
Sometimes you only need to store a date, lets say a birthdate. This will easily fit in a Calendar. You can ignore the other values. However the implementation will not. However the Calendar implementation will not. And if you add 24 hours you might someday end up at 01:00 or 23:00 in case of daylight savings areas. Even if you are only a couple of seconds off, they will not compare as equal.
At least wrap it in a separate class. For example the joda-time library has a DateTimeMidnight with times forced to 0 to represent the rest of the day. If your time-unit is lets say hours then define a separate class for it. Make sure you have testcase crossing different timezones and daylight savings boundaries.