NSCalendarUnit's interval property makes some invalid assumptions about dates.

[naoty]

NSCalendarUnit's interval property makes some invalid assumptions about dates.

[naoty]

@sstigler As you said, this library has incorrect assumptions. This problem was discussed at #9. I think we need to return constant values because Duration doesn't have any context about current time. Do you have any better idea?

[naoty]

@sstigler If you have any better idea, please send a pull request! I'm looking forward to it. I close this issue.

[sstigler]

@naoty I might do that eventually. I probably don't completely understand the purpose of the Duration class, but the gist of what I'd recommend is to represent the Ints as NSDateComponents instead of Durations.

[maelp]

I think the Duration class might be misleading indeed for those reasons, and should probably be represented as a stack of consecutive NSDateComponents if you want to add them, because "date + (1.month + 1.day)" cannot be coerced to "date + (31.day)", so you need to keep the internal representation as a stack if you want to be able to make correct computations afterwards

Otherwise I'd suggest not allowing to add / subtract Duration and force them to be added to dates immediately, so someone has to do: "(date + 1.month) + 1.day" which then has the current date context and uses NSCalendar to disambiguate the correct number of days

Would this be a solution?

[naoty]

@maelp Thank you for suggestion! I agree with you.

While the addition/subtraction of Duration with NSDate is possible, the exact conversion of Duration into NSTimeInterval is impossible because Duration doesn't know current datetime. Current implementation is useful but misleading.

I think the correctness of calculating dates is most important for date calculation libraries. So, I agree that the conversion of Duration into NSTimeInterval and the comparison between Durations should not be allowed.

@mattijsf, what do you think?

[naoty]

@maelp I decided to deprecate these computations. These will be obsoleted in 0.5.0. Would you check #30?

[maelp]

Indeed I feel it is a better solution, just allow people to do common things that are unambiguous, like adding a set number of days / hours / minutes / seconds to a date using NSCalendar to account for eg a day with an hour less because of DST, but not adding the durations together

[naoty]

@maelp Thanks! I will merge this pull request and close this issue.