Subject: [calsify] JSCalendar, recurrenceId and timezones.

From: Michael Douglass <[email-masked]>
Date: Sun, 23 Aug 2020 00:19:26 -0400

I find the explanations about recurrenceId a little confusing.

To be or not to be...

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.

It MUST appear in a 'detached' instance which represents a single 
override - for example being invited to a single instance.

Or - we could say it MAY appear in the override but its value MUST be 
the same as the key.

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?

I would suggest it shouldn't be.

As it relates to jscalendar:

The override keys are the local date time as calculated based on the 
master start using the master timezone.

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.

In iCalendar it's easy (I think). The recurrenceId timezone is distinct 
from the dtstart timezone so if I want one instyance of my meeting in 
London instead of New York I can easily override it. An example in 
jscalendar would help (me).

---

From: Michael Douglass <[email-masked]>
Date: Sun, 23 Aug 2020 18:37:35 -0400

This is an example of where I have difficulties:

BEGIN:VEVENT
DTEND;TZID=Europe/London:20200827T130000
ORGANIZER;CN=Michael Douglass;EMAIL=[email-masked]:mailto:2_GM4T
  GNJSHAZTSMZVGI4DGOJTGX342WLDXXBYOPRLNIH6PUKD7HMX2AYEEI52OIDOFAJCM5XGOLY7
  [email-masked]
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=[email-masked];RSVP=TRUE;PARTSTA
  T=NEEDS-ACTION:mailto:[email-masked]
ATTENDEE;CN=Michael Douglass;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;ROLE=CHA
  IR;EMAIL=[email-masked]:/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".

That might work sort of - the recurrenceid in this case could be treated 
just as a key.

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".

But how about this:

BEGIN:VEVENT
DTEND;TZID=America/New_York:20200828T100000
ORGANIZER;CN=Michael Douglass;EMAIL=[email-masked]:mailto:2_GM4T
  GNJSHAZTSMZVGI4DGOJTGUDTHTEQ47GRCQU725D74QKVDMJ6TIUAYENN7IGVHNMGQQKRVUJC
  [email-masked]
UID:BC776256-F1C6-4B1D-95AF-EEBD27C8E622
DTSTAMP:20200823T221311Z
SEQUENCE:1
RECURRENCE-ID;TZID=America/New_York:20200828T090000
SUMMARY:Test rid + tzid
LAST-MODIFIED:20200823T222119Z
DTSTART;TZID=America/New_York:20200828T090000
CREATED:20200823T221135Z
ATTENDEE;CUTYPE=INDIVIDUAL;EMAIL=[email-masked]:mailto:mdouglass@
  bedework.com
ATTENDEE;CN=Michael Douglass;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;ROLE=CHA
  IR;EMAIL=[email-masked]:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOh
  cljjCSqMYrUXDcs6f1z7CyXejTR/principal/
END:VEVENT
BEGIN:VEVENT
DTEND;TZID=Europe/London:20200827T130000
ORGANIZER;CN=Michael Douglass;EMAIL=[email-masked]:mailto:2_GM4T
  GNJSHAZTSMZVGI4DGOJTGUDTHTEQ47GRCQU725D74QKVDMJ6TIUAYENN7IGVHNMGQQKRVUJC
  [email-masked]
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=[email-masked];PARTSTAT=NEEDS-AC
  TION;RSVP=TRUE:mailto:[email-masked]
ATTENDEE;CN=Michael Douglass;CUTYPE=INDIVIDUAL;PARTSTAT=ACCEPTED;ROLE=CHA
  IR;EMAIL=[email-masked]:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOh
  cljjCSqMYrUXDcs6f1z7CyXejTR/principal/
END:VEVENT

On 8/23/20 00:19, Michael Douglass wrote:
> It looks like it should never appear anywhere for a full calendar 
> object with master and 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?
>
> In iCalendar it's easy (I think). The recurrenceId timezone is 
> distinct from the dtstart timezone so if I want one instyance of my 
> meeting in London instead of New York I can easily override it. An 
> example in jscalendar would help (me).
>
>

---

From: "Neil Jenkins" <[email-masked]>
Date: Mon, 24 Aug 2020 10:04:14 +1000

> with master and overrides.

Correct.

> 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 

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.

> the master dtstart. Is it valid to have a recurrenceid with a different 

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).

> master start using the master timezone.

Yes.

> 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.

> 
> 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?

 bedework.com

How about it? You have two individual instances, one with recurrenceId 2020-08-28T09:00:00 and the other 2020-08-27T09:00:00. The former object has time zone America/New_York and the latter Europe/London.

Neil.

---

From: Michael Douglass <[email-masked]>
Date: Sun, 23 Aug 2020 20:55:14 -0400

On 8/23/20 20:04, Neil Jenkins wrote:
>> ORGANIZER;CN=MichaelDouglass;EMAIL=[email-masked]:mailto:2_GM4T  <mailto:Douglass;EMAIL=[email-masked]:mailto:2_GM4T>
>>   [email-masked]  <mailto:[email-masked]>
>> ATTENDEE;CUTYPE=INDIVIDUAL;EMAIL=[email-masked]:mailto:mdouglass@  <mailto:ATTENDEE;CUTYPE=INDIVIDUAL;EMAIL=[email-masked]:mailto:mdouglass@>
>>   bedework.com
>>   IR;EMAIL=[email-masked]:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOh  <mailto:IR;EMAIL=[email-masked]:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOh>
>> ORGANIZER;CN=MichaelDouglass;EMAIL=[email-masked]:mailto:2_GM4T  <mailto:Douglass;EMAIL=[email-masked]:mailto:2_GM4T>
>>   [email-masked]  <mailto:[email-masked]>
>> ATTENDEE;CUTYPE=INDIVIDUAL;EMAIL=[email-masked];PARTSTAT=NEEDS-AC  <mailto:ATTENDEE;CUTYPE=INDIVIDUAL;EMAIL=[email-masked];PARTSTAT=NEEDS-AC>
>>   IR;EMAIL=[email-masked]:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOh  <mailto:IR;EMAIL=[email-masked]:/aMzkzNTI4MzkzNTI4MzkzNQPuXCcDTdG5iXfOh>
> How about it? You have two individual instances, one with recurrenceId 
> 2020-08-28T09:00:00 and the other 2020-08-27T09:00:00. The former 
> object has time zone America/New_York and the latter Europe/London.

If I'm sent the jscalendar version I can't construct a valid/correct 
representation of it as iCalendar.

What's going to come back to the organizer as a reply? Probably 
something with incorrect recurrenceids

>
> Neil.
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: "Neil Jenkins" <[email-masked]>
Date: Mon, 24 Aug 2020 10:56:30 +1000

On Mon, 24 Aug 2020, at 10:55, Michael Douglass wrote:
> If I'm sent the jscalendar version I can't construct a valid/correct representation of it as iCalendar.
> What's going to come back to the organizer as a reply?

If you were sent JSCalendar, presumably the sender will accept JSCalendar in return so it doesn't matter.

Neil.

---

From: Michael Douglass <[email-masked]>
Date: Mon, 24 Aug 2020 00:07:13 -0400

On 8/23/20 20:56, Neil Jenkins wrote:
> If you were sent JSCalendar, presumably the sender will accept 
> JSCalendar in return so it doesn't matter.

Only if the recipient knows to respond in jscalendar. It may not.

I think essentially your saying that iTip won't work correctly in 
certain cases if we mix iCalendar and jscalendar?

---

From: "Neil Jenkins" <[email-masked]>
Date: Mon, 24 Aug 2020 16:05:48 +1000

> Only if the recipient knows to respond in jscalendar. It may not.

If the recipient doesn't understand JSCalendar they will respond to the iCalendar version (which you will have to include for iMIP for sometime at least, as you have no idea what the recipient's server supports). If they do understand JSCalendar and respond to the JSCalendar then the situation is irrelevant. So the issue would be only if you receive it as JSCalendar but respond with iCalendar, and I can't really see why you would do that?

Neil.

---

From: Ken Murchison <[email-masked]>
Date: Wed, 26 Aug 2020 15:20:21 -0400

On 8/23/20 8:04 PM, Neil Jenkins wrote:
> 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.
>
> 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).
>
> I don't really understand the question. This would change the start 
> time, but has no effect on the recurrence id.
>
>>   [email-masked]  <mailto:[email-masked]>
>> ATTENDEE;CUTYPE=INDIVIDUAL;EMAIL=[email-masked];RSVP=TRUE;PARTSTA  <mailto:ATTENDEE;CUTYPE=INDIVIDUAL;EMAIL=[email-masked];RSVP=TRUE;PARTSTA>
>> 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.
>

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

---

From: "Neil Jenkins" <[email-masked]>
Date: Thu, 27 Aug 2020 11:11:12 +1000

On Thu, 27 Aug 2020, at 05:20, Ken Murchison wrote:
> 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

This is just a matter of encoding the data in extra JSCalendar properties if needed, so something for the JSCalendar <-> iCalendar document to specify. Either:
 * The source document is JSCalendar, in which case the recurrence id is just the date.
 * The source document is iCalendar, in which case you can save the tz of the recurrence id (if different to the event's tz) in some custom property in case you need to convert back.
Neil.