First I’ll just note that the parsed date range is deliberately generous — it’s just intended to get the parser to skip events that are way outside our date range, for performance… there’s a second process later that narrows the parsed data down to the exact selected range.
That said, it does look like list view is not handling something correctly, because those earlier dates should not be showing up.
There also seems to be an issue with limitdays as you’re describing. It does get affected by the pastdays value… e.g. setting limitdays="100" and pastdays="7" would result in the farthest future date being 93 days from today… if everything is working properly, which it does not appear to be here, of course.
I’ll have to look into both of these issues further.
I don’t think the changes to r34ics_boolean_check() (noted in your other post) are likely to be involved with this issue, but it’s possible, since these problems were not observed before. Let me know if these issues persist after you update to 5.4.0.1. Thanks.
5.4.0.1 doesn’t fix it.
I looked more closely at the code of this one and can see the cause.
The issue arises in class-r34ics.php, in the case statement around lines 457-482, in both the 'list' and 'month' cases, where $first_date is given a value when $pastdays is non-empty. The gmmktime() function call computes the first date by counting back from the beginning of the month, not from “today”.
Change gmmktime(0,0,0,date('n'),-$pastdays,date('Y')) to gmmktime(0,0,0,date('n'),date('j')-$pastdays,date('Y')) and it fixes it:-)
Thanks for looking into that. It’s complicated a bit though by the fact that I want it to be calculating from the first of the month, at least in month view, so the current month’s events are all shown. That code probably needs a general once-over at this point anyway. I’ll be doing more concerted work on the plugin next week.
Taking a closer look at this, you’ve found what is clearly a bug… yes, it should have been coded as you described, not just -$pastdays. (Knowing my own coding habits, if this had been intentional, I definitely would have made it 0-$pastdays, not just -$pastdays.)
I’m preparing version 5.4.1 right now, which will include this fix. Thanks for identifying this issue.
