Currently, when biweekly parses an iCalendar object, the object's timezone information is stored separately from the parsed ICalendar object. The idea behind this was that, because a date/time value can be formatted in any number of timezones, the timezone that a date is formatted in is more of a serialization matter, and should be separated from the "raw" iCalendar data.
For example, if a DTSTART property is formatted in the "America/New_York" timezone (as opposed to UTC time), then the property's date value is parsed according to that timezone and saved to the ICalendar object as a Java Date object (which does not retain the timezone that the date was parsed under). The fact that the property was originally formatted in "America/New_York" time is stored in a separate TimezoneInfo object, obtained by calling ICalReader.getTimezoneInfo() immediately after parsing the ICalendar object.
However, this becomes a problem with recurrence rules. They require a timezone in order to properly compute the date/value values they cover. Therefore, it is vitally important that the timezone in the original iCalendar file be preserved and be treated as part of the "raw" iCalendar data.
A possible fix for this problem would be to store the TimezoneInfo object inside the ICalendar object. This way, the TimezoneInfo object is more securely "attached" to its ICalendar object.
Currently, when biweekly parses an iCalendar object, the object's timezone information is stored separately from the parsed
ICalendar
object. The idea behind this was that, because a date/time value can be formatted in any number of timezones, the timezone that a date is formatted in is more of a serialization matter, and should be separated from the "raw" iCalendar data.For example, if a DTSTART property is formatted in the "America/New_York" timezone (as opposed to UTC time), then the property's date value is parsed according to that timezone and saved to the
ICalendar
object as a JavaDate
object (which does not retain the timezone that the date was parsed under). The fact that the property was originally formatted in "America/New_York" time is stored in a separateTimezoneInfo
object, obtained by callingICalReader.getTimezoneInfo()
immediately after parsing theICalendar
object.However, this becomes a problem with recurrence rules. They require a timezone in order to properly compute the date/value values they cover. Therefore, it is vitally important that the timezone in the original iCalendar file be preserved and be treated as part of the "raw" iCalendar data.
A possible fix for this problem would be to store the
TimezoneInfo
object inside theICalendar
object. This way, theTimezoneInfo
object is more securely "attached" to itsICalendar
object.