Graph: Support keeping separate start and end timezones on events

[tmcqueen-materials]

And here is one more nit/edge case -- for a new event with different timezones for start and end dates/times, davmail correctly handles the difference and has the correct start/end. However, when such an event is retrieved via davmail, the start and end timezone use the same timezone, instead of the two different timezones for the two datetimes.

This is purely a cosmetic issue -- the datetimes are correct (e.g. a 2 hr event starting at 2 PM in central standard time and ending at 3 PM in mountain standard time, is correctly 2 hrs in length, but the retrieved ICS file reports it as 2 PM in central standard time to 4 PM in central standard time).

I believe in the earlier TZ handling work there was briefly a partial fix for this, but it didn't do it completely. But I think a proper fix for this involves making sure davmail can handle an arbitrary number of VTIMEZONE objects in a single ICS file -- because not only are there start and end timezones, but each modifiedOccurrence or exdate could also be in a yet different timezone. But as it is cosmetic, I peg this as not an urgent item to fix.

Thank you!

[mguessan]

Marking as request for enhancement, you are right the tricky part is adding additional VTIMEZONE to event if we want to track different timezone for start/end dates.

In addition I noticed during testing that Gmail just blocks this option on recurring events, this seems to confirm trying to handle this on recurring events could become a mess.

As you mentioned this is cosmetic: as long as an incoming event is properly created the date/time will appear correctly on client.