Stefan's comment was actually very close to my line of thinking in designing Datetime.jl (which needs to be officially deprecated soon....). After looking through several other libraries/languages of Date implementations, my conclusion is that most end up using an Interval type vs. using Period types because it's too costly to create custom types, or too difficult to overload the needed behaviors to get types talking, or it's just too hard to get good performance. Thankfully, Julia suffers from none of these problems, and so providing a clean Date/Period implementation is clean, simple, and performant. If you have real, full-class Period types, it really simplifies a lot of the interactions and you really don't need an Interval type. TimeTypes represent moments in a timelines at a certain Period precision, and the difference between any two TimeTypes can be returned in the Period type of their precision.
-Jacob On Sun, Apr 20, 2014 at 4:55 PM, Stefan Karpinski <[email protected]>wrote: > On Sun, Apr 20, 2014 at 12:05 PM, Harlan Harris <[email protected]>wrote: > >> There are date/time-manipulation libraries where the difference between >> two dates is a date-interval, stored just as the endpoints. > > > This approach has some nice features, but I feel like it's just kicking > the can down the road and not really solving the problem. There's still the > question of what to do about this: date₁ + (date₂ - date₃). In what sense > did you mean to take the interval? Since you're taking the difference and > then adding it to a different starting point, you don't know what about > that difference was relevant. You could require writing something like > this: > > - date₁ + days(date₂ - date₃) > - date₁ + weeks(date₂ - date₃) > - date₁ + months(date₂ - date₃) > - date₁ + years(date₂ - date₃) > - date₁ + workdays(date₂ - date₃) > - date₁ + interestdays(date₂ - date₃) > > etc., although at that point, it's not entirely clear how much going > through an intermediary interval types is really buying you. >
