为了测试 google-rfc-2445 的性能，我运行了很多 RRULE。 (IETF RFC 2445 iCalendar 的 Java 实现)。
我看到我在某些情况下从该方法的返回列表中得到了开始日期。
测试很简单:
private static void runGoogleTests() throws ParseException
{
DateTimeZone dtz = DateTimeZone.UTC;
DateTime dtStart = new DateTime("2014-11-22T00:00:00Z", dtz);//SATURDAY
DateTimeIterable dti = DateTimeIteratorFactory.createDateTimeIterable("RRULE:FREQ=WEEKLY;COUNT=10;BYDAY=MO", dtStart, dtz, true);
System.out.println("Size of iterable = " + Iterators.size(dti.iterator()));
for(DateTime dateTime : dti)
{
System.out.println(dateTime);
}
}
工厂返回的列表返回这个列表。
第一个日期是开始日期，是一个不应该出现的星期六。 RRULE 还包含一个 COUNT=10 那么为什么要返回 11？
Size of iterable = 11
2014-11-22T00:00:00.000Z
2014-11-24T00:00:00.000Z
2014-12-01T00:00:00.000Z
2014-12-08T00:00:00.000Z
2014-12-15T00:00:00.000Z
2014-12-22T00:00:00.000Z
2014-12-29T00:00:00.000Z
2015-01-05T00:00:00.000Z
2015-01-12T00:00:00.000Z
2015-01-19T00:00:00.000Z
2015-01-26T00:00:00.000Z
以前使用 Google-rfc-2445 的人一定遇到过这个问题吧？
我在项目页面上发布了这个问题，但那里非常安静。 Link to the issue on google-rfc-2445 page
最佳答案
RFC2445 section 4.3.10 Recurrence Rule指定
[...] The COUNT rule part defines the number of occurrences at which to range-bound the recurrence. The "DTSTART" property value, if specified, counts as the first occurrence. [...]
所以当 DTSTART 存在时在返回列表中是正常的，不太期望的是返回列表的大小。
鉴于 RFC2445 规范，拥有 DTSTART 更有意义作为重复的第一个实例，以确保其他日历正确理解 ical 文件。
还要注意RFC2445已被 RFC5545 废弃它还指定了 DTSTART作为 RRULE 的第一个实例(甚至强调它，注意:添加的词 always (强调是我添加的)
RFC5545 RRULE section: The COUNT rule part defines the number of occurrences at which to range-bound the recurrence. The "DTSTART" property value always counts as the first occurrence.
关于java - 在某些情况下使用 google-rfc-2445 (iCalendar) 时会返回开始日期，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/27486705/