Month intervals calculated incorrectly (or unintuitively)

Issue #12 resolved
Former user created an issue

Given the following code:

import aniso8601, itertools
dates = aniso8601.parse_repeating_interval('R/2017-04-30T00:00:00Z/P1M')
print map(str, itertools.islice(dates, 0, 4))

I see:

['2017-04-30 00:00:00+00:00', '2017-05-30 00:00:00+00:00', '2017-06-29 00:00:00+00:00', '2017-07-29 00:00:00+00:00']

I expect to see:

['2017-04-30 00:00:00+00:00', '2017-05-30 00:00:00+00:00', '2017-06-30 00:00:00+00:00', '2017-07-30 00:00:00+00:00']

I have observed other iso8601-handling systems strive to maintain the same day of the month (adjusting as necessary) when handling intervals of one month or greater. iso8601 appears to treat a month as a synonym for 30 days.

Comments (2)

  1. Brandon Nielsen repo owner

    The current behavior is documented, years are also assumed to always be 365 days when parsing repeating intervals.

    That being said, I agree the behavior you described is more correct. I'll look into it.

  2. Brandon Nielsen repo owner

    The issue was with how the deltas used to generate dates in repeated interval are created. In versions prior to 1.2.1, the delta was recalculated from the interval part of the duration instead of coming directly from the duration part of the repeating interval, which results in the relative=True argument being ignored.

    With 1.2.1, the delta is not recalculated after parsing the interval, so the relative=True keyword is applied correctly to repeating intervals:

    >>> import aniso8601, itertools
    >>> dates = aniso8601.parse_repeating_interval('R/2017-04-30T00:00:00Z/P1M', relative=True)
    >>> print map(str, itertools.islice(dates, 0, 4))
    ['2017-04-30 00:00:00+00:00', '2017-05-30 00:00:00+00:00', '2017-06-30 00:00:00+00:00', '2017-07-30 00:00:00+00:00']
    

    Thanks for the bug report and the test case!

  3. Log in to comment