ICalendar object is that I thought it would be cleaner to treat the timezone info as part of how an iCalendar is serialized. After all, an iCalendar object can have the same exact same date/time information, but encoded in a variety of different timezones. Please let me know if you encounter any other difficulties!
ICalReader.getTimezoneInfo() along with the ICalendar info.
BEGIN:VCALENDAR
METHOD:REPLY
BEGIN:VEVENT
DTSTAMP:20050317T164626Z
DTSTART:20050318T170000Z
UID:040000008200E00074C5B7101A82E00800000000A0DD17CECD2AC501000000000000000010000000DA4A35FDD8F70E4686F330A21558AF27
ATTENDEE;PARTSTAT=ACCEPTED;CN="Roland Schtroumpf":MAILTO:schtroumpf@example.com
LOCATION:866-555-3378, conf ID = 650-555-0500, passcode = 255455
DTEND:20050318T180000Z
END:VEVENT
END:VCALENDARVERSION), but that shouldn't lead to an NPE.
I have one question though: it looks like the DateIterators that I can generate never actually terminate - even though I have a
DTEND section under VEVENT, I still get iterator dates past the year 12,135!
event.getRecurrenceRule().getDateIterator(event.getDateStart(), tzinfo) or event.getDateIterator(event.getDateStart(), tzinfo)
UNTIL specified - so of course the DateIterator will be infinite!Sorry for the spam - thanks again for the awesome library! :D
(PS - can't wait until timezone info is included inside the ICalendar object! Maybe having a JodaTime plugin, which would allow you to make the
DateStart/End objects contain a DateTime, which knows about timezones?)
@mangstadt RE migrating to Java 1.8, what would that mean for Android Lollipop/Marshmallow support? Currently, only Android N supports 1.8 syntax.
One more question - if I wanted to use Biweekly to parse solely an RRULE, do you have any suggestions in regards to using the RecurrenceRuleScribe?
I'm currently initializing the Scribe using whatever compiles, which looks something like this:
RecurrenceRuleScribe scribe = new RecurrenceRuleScribe();
ParseContext pc = new ParseContext();
pc.setVersion(ICalVersion.V2_0);
ICalParameters icp = new ICalParameters();
RecurrenceRule rrule = scribe.parseText("FREQ=WEEKLY;BYDAY=MO,WE,FR", null, icp, pc);Is there a better way to be doing this?
RecurrenceRuleScribe correctly.
@mangstadt hopefully the last question for you!
I'm using RecurrenceRule.getDateIterator(startDate, timezone), and it's exhibiting the very expected behavior of "remembering" the last Date that it spat out. However, if I want to repeatedly check from the "beginning" (like, if the user exits a screen and comes back, and I need to show the first date again, etc.), is there a way to "reset" the DateIterator? I've tried DateIterator.advanceTo(Date), but that ignores the input if input < current.
Am I stuck with just calling RecurrenceRule.getDateIterator(startDate, timezone) every time I need to reset?
@mangstadt I know I've been asking a lot of questions, and I apologize!
But I think I've found a small bug in the DateIterable created from DateIteratorFactory.createDateIterable(String, Date, TimeZone, boolean).
The bug is: if I create a DateIterable with a Date (e.g., July 17, 2016 @ 14:00) and timezone=PDT, the DateIterable doesn't entirely respect the timezone I input -- it spits out a Date with UTC time (e.g., July 19, 2016 @ 21:00). The workaround is to initialize the DateIterable with UTC time, but it isn't readily apparent that that's what a user should do.
I've written a small script that reproduces this issue (see below). I originally wrote it using org.joda.DateTime objects, but someone pointed out that I should use java.util.Date to reduce confounding variables. Let me know if I'm doing anything funky as a result - I don't use java.util.Date much.
I suspect that one of the issues is in DateIteratorFactory#dateToDateValue(Date, boolean), but it might be deeper in the iterator generator code. (I also realize that this is code ported from Google's RFC2445 lib, so feel free to tell me that this isn't your problem anymore :) )
Script that repros this issue:
TimeZone timezone_pdt = TimeZone.getTimeZone("America/Los_Angeles");
Date startDate = new Date(2016, 7, 17, 14, 0, 0);
DateIterable workaroundIterable = DateIteratorFactory.createDateIterable("RRULE:FREQ=WEEKLY;BYDAY=TU", startDate, DateTimeZone.UTC.toTimeZone(), true);
DateIterable PDTInitializedIterable = DateIteratorFactory.createDateIterable("RRULE:FREQ=WEEKLY;BYDAY=TU", startDate, timezone_pdt, true);
int count = 3;
SimpleDateFormat sdf_pdt = new SimpleDateFormat("EEE MMM dd HH:mm:ss zzz");
sdf_pdt.setTimeZone(timezone_pdt);
SimpleDateFormat sdf_default = new SimpleDateFormat("EEE MMM dd HH:mm:ss zzz");
for (DateIterator pdtIter = PDTInitializedIterable.iterator(), workaroundIter = workaroundIterable.iterator(); pdtIter.hasNext() && workaroundIter.hasNext();) {
Date pdtNext = pdtIter.next();
Date utcNext = workaroundIter.next();
System.out.println("Next PDT-initialized-iterable time: \t" + sdf_pdt.format(pdtNext)); // should be "14:00:00 PDT", but is "...21:00:00 PDT"
System.out.println("Next workaround-created time: \t\t" + sdf_default.format(utcNext));
System.out.println();
if (--count == 0)
break;
}Output:
Next PDT-initialized-iterable time: Thu Aug 17 21:00:00 PDT
Next workaround-created time: Thu Aug 17 14:00:00 PDT
Next PDT-initialized-iterable time: Tue Aug 22 21:00:00 PDT
Next workaround-created time: Tue Aug 22 14:00:00 PDT
Next PDT-initialized-iterable time: Tue Aug 29 21:00:00 PDT
Next workaround-created time: Tue Aug 29 14:00:00 PDTTimeZone timezone_pdt = TimeZone.getTimeZone("America/Los_Angeles");
TimeZone.setDefault(timezone_pdt);
Calendar c = Calendar.getInstance();
c.clear();
c.set(Calendar.YEAR, 2016);
c.set(Calendar.MONTH, Calendar.AUGUST);
c.set(Calendar.DATE, 17);
c.set(Calendar.HOUR_OF_DAY, 14);
Date start = c.getTime();
Recurrence recur = new Recurrence.Builder(Frequency.WEEKLY).byDay(DayOfWeek.TUESDAY).build();
RecurrenceRule rrule = new RecurrenceRule(recur);
DateIterator it = rrule.getDateIterator(start, timezone_pdt);
int count = 3;
while (--count >= 0) {
System.out.println(it.next());
}@mangstadt I believe that does work -- I was using it previously.
The reason why I switched to DateIteratorFactory.getDateIterable() is because it returns a DateIterable, which allows me to create a new Iterator instance upon every call to iterator(). Especially when using enhanced for-each syntax, it's then easy to ensure that we don't cache/reuse an old instance of the DateIterator.
Of course, the other workaround it just to pass the createDateIterable() method a UTC timezone, which is easy enough to do.
Either way, figured I'd send the bug report your way. Thanks for finding another workaround! :)
