That's right Ivar. The current arithmetic rules for Date/DateTime + Year/Month approach the ambiguity problem by a strategy of "minimum edit distance". For those who don't know, edit distance is the minimum number of required operations to transform one string into another, with the operations including deleting a character, adding a character, and substituting a character with another. For dates, this means that if you add one year to 2012-02-29, we have to increment the year by one, which gives us 2013-02-29, and then we reduce the day by one to result in 2013-02-28, since this only requires one operation as opposed to incrementing the month by one and wrapping the day to one, which is two operations. In practice, this means that the last day of the month is special or "sticky" in that if you add a year or month and the date is the last day of the month, the result will tend to "stick" to the last day of the month if the result would "overflow" to the next month. So 2014-01-31 + Month(1) = 2014-02-28, while 2014-02-28 + Month(1) = 2014-03-28.
Is this the best way to resolve this ambiguity? I don't know. The reason I went with this approach is because it's performant, consistent, and not too difficult to explain and document. It also doesn't require "user resolution methods" which is Java 8's new approach (e.g. if an operation has an ambiguous result, an error is thrown if the user doesn't provide a method for resolving the ambiguity). If anyone has a better idea, I'd definitely be open to hearing, but so far this has seemed to work out pretty well. -Jacob On Mon, Apr 21, 2014 at 8:40 AM, Ivar Nesje <[email protected]> wrote: > I would try something like > > julia> date("2004-02-29") + year(18) > 2022-02-28 > > But it seems we round the opposite way of your definition. > > Ivar > > > kl. 09:22:00 UTC+2 mandag 21. april 2014 skrev MikeEI følgende: > >> Jacob, Datetime is great and looking forward to new base. >> >> "Human" time periods are interesting. E.g. important day in Germany is >> 18th birthday (allowed to drive ...). Regulation: You completed 18 years >> (as any other year) on Your birthday 0:00. So the day of one's birth >> counts. If born on a Feb 29, You completed 18 years on Mar 01. >> How would one calculate (18th) birthday <purely> with new base/datetime >> means? >> >> >> Am Montag, 21. April 2014 02:53:18 UTC+2 schrieb Jacob Quinn: >>> >>> 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. >>>> >>> >>>
