Re: [calsify] JSCalendar, recurrenceId and timezones.

[Ken Murchison <[e-mail]>]

On 8/23/20 8:04 PM, Neil Jenkins wrote:
> On Sun, 23 Aug 2020, at 14:19, Michael Douglass wrote:
>> When is it valid to actually have a recurrenceId property and if it
>> exists what are the constraints?
>>
>> It looks like it should never appear anywhere for a full calendar object
>> with master and overrides.
>
> Correct.
>
>> It MUST appear in a 'detached' instance which represents a single
>> override - for example being invited to a single instance.
>
> Correct.
>
>> Or - we could say it MAY appear in the override but its value MUST be
>> the same as the key.
>
> No, see section 4.3.3 
> <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-27#section-4.3.3>; 
> it's in the list of keys that you can't override.
>
>> On timezones in overrides
>>
>> I haven't found anything in 5545 that says the tzid MUST be the tzid in
>> the master dtstart. Is it valid to have a recurrenceid with a different
>> timezone?
>
> The recurrence id doesn't have a time zone (or if you prefer to think 
> of it this way: its time zone is always that of the master event).
>
>> The override keys are the local date time as calculated based on the
>> master start using the master timezone.
>
> Yes.
>
>> What happens if an override changes the timezone? We can't use the
>> recurrenceId value as that's the local time in the master timezone.
>
> I don't really understand the question. This would change the start 
> time, but has no effect on the recurrence id.
>
>> This is an example of where I have difficulties:
>>
>> BEGIN:VEVENT
>> DTEND;TZID=Europe/London:20200827T130000
>> ORGANIZER;CN=MichaelDouglass;EMAIL=[e-mail]:mailto:2_GM4T  <mailto:Douglass;EMAIL=[e-mail]:mailto:2_GM4T>
>>   GNJSHAZTSMZVGI4DGOJTGX342WLDXXBYOPRLNIH6PUKD7HMX2AYEEI52OIDOFAJCM5XGOLY7
>>   [e-mail]  <mailto:[e-mail]>
>> UID:BC776256-F1C6-4B1D-95AF-EEBD27C8E622
>> DTSTAMP:20200823T221311Z
>> SEQUENCE:1
>> RECURRENCE-ID;TZID=America/New_York:20200827T090000
>> SUMMARY:Test rid + tzid
>> LAST-MODIFIED:20200823T221349Z
>> DTSTART;TZID=Europe/London:20200827T120000
>> CREATED:20200823T221135Z
>> ATTENDEE;CUTYPE=INDIVIDUAL;EMAIL=[e-mail];RSVP=TRUE;PARTSTA  <mailto:ATTENDEE;CUTYPE=INDIVIDUAL;EMAIL=[e-mail];RSVP=TRUE;PARTSTA>
>>   T=NEEDS-ACTION:mailto:[e-mail]
>> ATTENDEE;CN=Michael Douglass;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;ROLE=CHA
>>   IR;EMAIL=[e-mail]:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOh  <mailto:IR;EMAIL=[e-mail]:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOh>
>>   cljjCSqMYrUXDcs6f1z7CyXejTR/principal/
>> END:VEVENT
>>
>> When that's converted to jscalendar we will have a recurrence id 
>> based on "America/New_York"- which won't appear anywhere - and a 
>> start time based on "Europe/London".
>>
>
> Yes, America/New_York will not appear anywhere. if you don't have the 
> master event, it's not relevant. The recurrence id is used to identify 
> unique instances of recurring events. Because we need to be able to 
> generate an id for recurrences created by a recurrence rule, we use 
> the generated date-time as the id. But it is still just an id, not a 
> date. You can override the date of an occurrence (including the time 
> zone of the date), but you can't override its id.
>
>> But what if that gets sent out as jscalendar and the recipient has to 
>> convert back to icalendar - what timezone do they use for the 
>> recurrenceid? Best guess is he wrong one "Europe/London".
>>
>
> Is there a situation where this is actually going to make a difference 
> though?


Maybe, but I don't think we have done enough testing to know for sure 
either way.  I think it would be wise for us to do some interop testing 
among different vendors (we now have at least 2), especially when it 
comes to scheduling and iTIP.  The Apple CalDAVTester has a healthy set 
of tests, including edge-cases such as above, and would be a good base 
to start from.

The Fastmail/Cyrus server stores calendar resources internally as 
iCalendar so it routinely converts JSCalendar -> iCalendar -> 
JSCalendar.  I think that we have said that not all JSCalendar resources 
can be represented as iCalendar, but if the reverse ends up being true, 
I think we are making a mistake if we publish without addressing any 
such shortcomings as it would likely hinder adoption.


-- 

Kenneth Murchison
Senior Software Developer
Fastmail US LLC