Subject: Re: [calsify] JSCalendar: duration normalization and weeks

From: Andri Möll <[email-masked]>
Date: Wed, 5 Sep 2018 19:31:49 +0000

> I'll wait with a RFC version update until end of this week in case further feedback comes up.
>
> Cheers,
> Robert

In light of things finalizing, I'd like to re-raise the nominal duration 
issue. As I may not be able to convince everyone of their value and 
accept their exclusion from the spec, I strongly recommend they NOT be 
allowed to be specified for events with times. That is, P1D should only 
be allowed for events with dates. Both for consistency and for future 
proofing.

The first thing I learned when getting into calendaring, and something 
every course and book teaches you, is that days are not consistently 24 
hours, months not 30 days and years not 365 days. It's _the_factoid  
every time-enlightened person tells the uninitiated. Going against that 
in a calendaring spec is backwards and error prone.

It's especially error prone because the difference between nominal and 
accurate durations is encoded not only into brains, but into libraries. 
Take JodaTime for Java, NodaTime for C# or Moment.js for JavaScript as 
examples. All are fine to reach out for when implementing basic time 
arithmetic, and all handle nominal durations as you'd expect --- moving 
the wall clock time forward a day, NOT by adding 24 hours. I know the 
spec _really_ refers to ISO 8601 as inspiration for the duration format, 
but that's irrelevant. If it quacks like ISO 8601, it's ISO 8601. No-one 
wants to, nor should they, reimplement duration arithmetic just because 
of this quirk. I know I sure won't.

As we're not going to standardize nominal durations for events with 
times, they should be forbidden.

On 7/5/18 12:47 AM, Neil Jenkins wrote:
> On Thu, 5 Jul 2018, at 10:16 AM, Ronald Tse wrote:
>> I’d like to remind ourselves that the "exact duration" of any time 
>> scale unit (except for the second) already depends on the start. The 
>> leap second modifies the exact duration of the last minute, the last 
>> hour, the last day of the year, etc.
>
> I don't believe any current (at least common) calendar implementations 
> implement leap seconds. While I appreciate your pedantry here, for the 
> purposes of JSCalendar I expect most implementations to treat minutes, 
> hours, days, weeks as fixed multiples of seconds.
>
>> The simple way of dealing with P1D, P1M, P1Y is to find the 
>> corresponding nominal duration. P1D will lead to the same time in a 
>> day after, whether it is a normal day or a leap day. P1M will lead to 
>> the same day in the next month. P1Y will lead to the same month day 
>> in the next year regardless if it is a leap year.
>
> As has been pointed out, this is not, in fact, simple, e.g. 31 July, 
> 29 Feb. I'm sure future ISO 8601 revisions can come up with ever more 
> complicated rules for how to handle this, but I come back to the point 
> that the added complexity here outweighs the meagre benefits in 
> functionality.
>
> Neil.
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: Andrew Laurence <[email-masked]>
Date: Wed, 05 Sep 2018 23:41:40 -0700

> On Sep 5, 2018, at 12:31 PM, Andri Möll <[email-masked]> wrote:
> 
> In light of things finalizing, I'd like to re-raise the nominal duration issue. As I may not be able to convince everyone of their value and accept their exclusion from the spec, I strongly recommend they NOT be allowed to be specified for events with times. That is, P1D should only be allowed for events with dates. Both for consistency and for future proofing.

Could the period duration constrained to not exceed the logical bounds of the prior unit?  e.g. P1M6W is invalid because no Gregorian month has six weeks.

> The first thing I learned when getting into calendaring, and something every course and book teaches you, is that days are not consistently 24 hours, months not 30 days and years not 365 days. It's _the_factoid  every time-enlightened person tells the uninitiated. Going against that in a calendaring spec is backwards and error prone.

I love using this for that conversation:
http://yourcalendricalfallacyis.com

-Andrew

---

From: Andri Möll <[email-masked]>
Date: Thu, 6 Sep 2018 10:41:43 +0000

> Could the period duration constrained to not exceed the logical bounds of the prior unit?  e.g. P1M6W is invalid because no Gregorian month has six weeks.

For the record, how and whether to limit nominal durations is 
independent of permitting them in the first place. My proposal was to 
forbid them for events with times right now as the P1D == PT24H 
equivalence the spec supposedly assumes is just silly.

As for limiting nominal durations, I don't agree. While ISO 8601 doesn't 
allow weeks to be specified along with anything else, even if it did, 
weeks decompose to days and days are one of the atoms, along with 
seconds and months. P1M6W would be as permissible as P1M42D.

---

From: Robert Stepanek <[email-masked]>
Date: Thu, 06 Sep 2018 06:45:36 -0400

On Thu, Sep 6, 2018, at 12:42, Andri Möll wrote:

>  My proposal was to 

I'm not sure which spec you mean? The JSCalendar spec doesn't assume equivalence of P1D and PT24H.

Cheers,
Robert

---

From: Andri Möll <[email-masked]>
Date: Thu, 6 Sep 2018 11:03:32 +0000

> I'm not sure which spec you mean? The JSCalendar spec doesn't assume equivalence of P1D and PT24H.

I was going off of Neil's conclusion and the convert-to-UTC aspect:

On 7/4/18 11:10 PM, Neil Jenkins wrote:

> No, see the actual spec 
> <https://tools..ietf.org/html/draft-ietf-calext-jscalendar-05#section-5.1.3>:
>
> *
>
>
>         5.1.3
>         <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-05#section-5.1.3>.
>         duration
>
> *
> Type: "Duration", e.g. "P2DT3H" (optional, default: "P0D") The zero or 
> positive duration of the event in absolute time (i.e. in UTC time; 
> ignoring DST shifts).
>
> Therefore, P1D is exactly equivalent to PT24H in the context of the 
> event duration.
I'd be surprised if anyone pays attention to the UTC-conversion 
idiosyncrasy. It's natural, in the context of calendaring, to do 
arithmetic on date-times [objects] with time zones (for events with 
times), as you want the end time to be in the same time zone, after all. 
And it'll work just fine because +PT3H is the same in any time zone. 
+P1D however will diverge. It's an error prone idiosyncrasy I'm arguing 
should be dropped --- no P1Ds for events with times.

---

From: Robert Stepanek <[email-masked]>
Date: Tue, 11 Sep 2018 09:04:40 -0400

On Thu, Sep 6, 2018, at 13:03, Andri Möll wrote: 
> No, see the actual spec <https://tools..ietf.org/html/draft-ietf-calext-jscalendar-05#section-5.1.3>: 
>>  
>> 5.1.3 <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-05#section-5.1.3>.  duration
>> 

   Type: "Duration", e.g.  "P2DT3H" (optional, default: "P0D")

   The zero or positive duration of the event in absolute time (i.e. in
   UTC time; ignoring DST shifts).
>> 
>>  
>> Therefore, P1D is exactly equivalent to PT24H in the context of the event duration. 
> I'd be surprised if anyone pays attention to the UTC-conversion idiosyncrasy. It's natural, in the context of calendaring, to do arithmetic on date-times [objects] with time zones (for events with times), as you want the end time to be in the same time zone, after all. And it'll work just fine because +PT3H is the same in any time zone. +P1D however will diverge. It's an error prone idiosyncrasy I'm arguing should be dropped --- no P1Ds for events with times.  
 
Doesn't your proposal in fact require all events with isAllDay=false to omit days and weeks from durations? 
 
Looking at the relevant sections of RFC 5545: 
 
https://tools.ietf.org/html/rfc5545#section-3.3.6 
  
      The duration of a week or a day depends on its position in the
      calendar.  In the case of discontinuities in the time scale, such
      as the change from standard time to daylight time and back, the
      computation of the exact duration requires the subtraction or
      addition of the change of duration of the discontinuity.
 
and later 
  
      When computing an exact duration, the greatest order time
      components MUST be added first
 
it indeed looks to me as if there is a gap between JSCalendar and iCalendar durations (but I'm not sure I parsing the first requirement right). 
 
I'd favour to keep JSCalendar aligend with iCalendar for durations. In my understanding that is: allow days (and weeks) for non-zero event times, but perform the addition in the event time-zone. For time gaps, P1D does not equal PT24H. Probably Neil has more insight how the JSCalendar duration spec came to its current definition? 
 
Cheers, 
Robert

---

From: Andri Möll <[email-masked]>
Date: Tue, 11 Sep 2018 14:00:21 +0000

> to omit days and weeks from durations?
It does. But I proposed it so only because I was under the impression 
the "proper" handling was not going to get in and I found the specified 
behavior --- P1D always being 24h (quoted below as 5.1.3) --- to be a 
poor choice. I'd be more than happy to see nominal durations for events 
with times (!isAllDay) be handled in the event's time zone --- like our 
interpretation of iCalendar seems to suggest.

On 9/11/18 1:04 PM, Robert Stepanek wrote:
>>> Type: "Duration", e.g. "P2DT3H" (optional, default: "P0D") The zero 
>>> or positive duration of the event in absolute time (i.e. in UTC 
>>> time; ignoring DST shifts).
>>>
>> times), as you want the end time to be in the same time zone, after 
>> all. And it'll work just fine because +PT3H is the same in any time 
>> zone. +P1D however will diverge. It's an error prone idiosyncrasy I'm 
>> arguing should be dropped --- no P1Ds for events with times.
>
> it indeed looks to me as if there is a gap between JSCalendar and 
> iCalendar durations (but I'm not sure I parsing the first requirement 
> right).
>
> I'd favour to keep JSCalendar aligend with iCalendar for durations. In 
> my understanding that is: allow days (and weeks) for non-zero event 
> times, but perform the addition in the event time-zone..  For time 
> gaps, P1D does not equal PT24H. Probably Neil has more insight how the 
> JSCalendar duration spec came to its current definition?
>
> Cheers,
> Robert
>