Subject: [calsify] jscalendar, alarm and related

From: Michael Douglass <[email-masked]>
Date: Mon, 25 Feb 2019 16:50:16 -0500

Why was it decided to have relatedTo = before/afterXXX and presumably 
have offset be positive only (as defined but not explicit I think)

This seems more cumbersome than the current related = start|end and a 
positive or negative duration for trigger.

I assume the idea was to disallow negative durations for events - which 
don't make sense but a negative duration for offset makes sense.

---

From: "Neil Jenkins" <[email-masked]>
Date: Mon, 25 Feb 2019 19:21:39 -0500

> have offset be positive only (as defined but not explicit I think)

Because RFC3339 <https://tools.ietf.org/html/rfc3339> only includes a definition for positive durations, so if we had negative ones we would have to define our own syntax (and may lose compatibility with parsers that have already been implemented following this specification).

Neil.

---

From: Michael Douglass <[email-masked]>
Date: Mon, 25 Feb 2019 22:12:00 -0500

On 2/25/19 19:21, Neil Jenkins wrote:
> Because RFC3339 <https://tools.ietf.org/html/rfc3339> only includes a 
> definition for positive durations, so if we had negative ones we would 
> have to define our own syntax (and may lose compatibility with parsers 
> that have already been implemented following this specification).
I don't think it needs a new syntax - it's (["+"] | "-") followed by 
duration.
>
> Neil.
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: "Neil Jenkins" <[email-masked]>
Date: Mon, 25 Feb 2019 22:14:33 -0500

On Tue, 26 Feb 2019, at 14:12, Michael Douglass wrote:
> I don't think it needs a new syntax - it's (["+"] | "-") followed by duration.

That's a new syntax by definition. And that doesn't go in to the point of existing object interpretations may not support negative durations (e.g. may use an unsigned int for the internal representation); the point is you may now have compatibility issues with existing code and whether this is sufficiently better to be worth that tradeoff.

Neil.

---

From: Michael Douglass <[email-masked]>
Date: Mon, 25 Feb 2019 22:19:26 -0500

On 2/25/19 22:14, Neil Jenkins wrote:
> That's a new syntax by definition. And that doesn't go in to the point 
> of existing object interpretations may not support negative durations 
> (e.g. may use an unsigned int for the internal representation); the 
> point is you may now have compatibility issues with existing code and 
> whether this is sufficiently better to be worth that tradeoff.

What existing code? This is in reference to alarms which in icalendar 
are specified by negative or positive trigger values. Any 
reimplementation of alarm code for jscalendar will have to take account 
of the difference.

 From icalendar 3.3.6

        dur-value  = (["+"] / "-") "P" (dur-date / dur-time / dur-week)

I already have a parser which handles negative durations. I already 
check for and disallow negative durations for events.

---

From: "Alexander Nimmervoll" <[email-masked]>
Date: Tue, 26 Feb 2019 08:34:37 +0100

I also think it should allow the same syntax as alarm trigger values and every iCalendar parser understands positive and negative durations for that. 

Another question is about the subset of the duration definition for JSCalendar. Why was the dur-date removed? This also leads to necessary conversions from alarm triggers.

Cheers,

Alex

What existing code? This is in reference to alarms which in icalendar are specified by negative or positive trigger values. Any reimplementation of alarm code for jscalendar will have to take account of the difference.

I already have a parser which handles negative durations. I already check for and disallow negative durations for events.

Neil.

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

---

From: Ken Murchison <[email-masked]>
Date: Thu, 28 Feb 2019 07:08:11 -0500

I'm in agreement with Mike and Alexander in that we should allow 
negative durations in jcalendar in the same fashion as iCalendar.

On 2/25/19 10:19 PM, Michael Douglass wrote:
>> That's a new syntax by definition. And that doesn't go in to the 
>> point of existing object interpretations may not support negative 
>> durations (e.g. may use an unsigned int for the internal 
>> representation); the point is you may now have compatibility issues 
>> with existing code and whether this is sufficiently better to be 
>> worth that tradeoff.
>
> reimplementation of alarm code for jscalendar will have to take 
> account of the difference.
>
> From icalendar 3.3.6
>

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Andrew Laurence <[email-masked]>
Date: Thu, 28 Feb 2019 12:06:29 -0800

IIRC, negative durations are in the 8601-2 draft.

-Andrew

> On Feb 28, 2019, at 4:08 AM, Ken Murchison <[email-masked]> wrote:
> 
> I'm in agreement with Mike and Alexander in that we should allow negative durations in jcalendar in the same fashion as iCalendar.
> 
> 
> 
>>> https://www.ietf.org/mailman/listinfo/calsify <https://www.ietf.org/mailman/listinfo/calsify>
>> 
>> 
>> https://www.ietf.org/mailman/listinfo/calsify <https://www.ietf.org/mailman/listinfo/calsify>
> -- 
> Ken Murchison
> Cyrus Development Team
> FastMail US LLC
> <murch.vcf>_______________________________________________
> calsify mailing list
> [email-masked]