Problem with Appointment.load when reading .ics files created by Aspose.mail 2.2.0

The Appointment.load() method does not seem to work when processing .ics files with recurrence rules that are created by aspose.email (version 2.2.0).



I’ve confirmed that the load method works with .ics files created by the Mac Calendar application. But using the load method on ics files created by saving meetings found in a PST file fails with a null pointer exception if the meeting has a recurrence rule. Here is the kind of code I’m using.



// Saving

MapiCalendar calendar = (MapiCalendar) pst.extractMessage(messageInfo).toMapiMessageItem();

try {

calendar.save(“foo.ics”, AppointmentSaveFormat.Ics);

} catch (Exception ex2) {

ex2.printStackTrace();

}



// Loading results in null pointer exception

Appointment app = Appointment.load(“foo.ics”);





Looking at the resulting “.ics” file, I suspect that something is wrong in the timezone or daylight savings sections. When I replace those sections with content created by the Mac calendar application, I do not get a failure.



Interestingly, I’m able to successfully parse the file with iCal4j.



To help you reproduce the problem, I’m including the file “RecurrTest.pst”. This PST contains 14 different recurring meetings, all of which will demonstrate the problem.



I also include “PSTExtractCalendar.java”, a program that read the calendar items from the PST and save them as .ics files as well as “OpenICS.java” which tries to open the .ics files and displays progress to the output console.



Note: this is a followup to the issue mentioned at the end of the thread on parsing recurring events (). It is possible to parse the PST appointments but we also need to be able to work with .ics files.

Hi Steven,


Thanks for writing to Aspose.Email support team.

We have analyzed the data and were able to reproduce the issue. We have passed this information to our development team for further analysis and will write back here on forum as soon as some feedback is received.

This issue is logged in our bug reporting system as NETWRKJAVA-33196.