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

From: Andri Möll <[email-masked]>
Date: Tue, 3 Jul 2018 23:30:04 +0000

> Side-note: at last CalConnect we discussed to allow all valid ISO8601 
> durations, including years and months. On second thought this would 
> require implementations to handle in-existent dates in date-time 
> arithmetic, and break iCalendar compatibility for no compelling reason.

While I don't think use of durations in years or months are that common, 
I can definitely see value in them for events like "an entire month 
every n months". If there's ever a time to fix old mistakes, now would 
be the time, wouldn't it? Switching from duration format /based on/ ISO 
8601 to ISO 8601 proper would be a rather mild change after all.

I haven't tested, so what do current implementations do given a full ISO 
8601 durations?

On 06/29/2018 09:39 AM, Robert Stepanek wrote:
> The current JSCalendar duration definition neither is strictly 
> normalized nor compatible with the iCalendar DURATION type. 
> Specifically, it normalizes the zero duration to be written as P0D but 
> does not define any other normalization. In addition, it does not 
> support durations expressed in weeks.
>
> It might make sense to either require completely  normalized 
> durations, or to support the full value range of iCalendar durations. 
> I lean towards the latter, and intend to:
>
>   * remove the P0D restriction for zero durations
>   * allow durations to be expressed in weeks, with the same
>     restrictions as iCalendar and ISO 8601 durations.
>
>
> While normalization can provide value in some cases, it is likely to 
> be ignored by clients and robust implementations will have to deal 
> with them already for iCalendar.
>
> Side-note: at last CalConnect we discussed to allow all valid ISO8601 
> durations, including years and months. On second thought this would 
> require implementations to handle in-existent dates in date-time 
> arithmetic, and break iCalendar compatibility for no compelling reason.
>
> What are your thoughts?
>
> Cheers,
> Robert
>
>
>
>
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

---

From: Neil Jenkins <[email-masked]>
Date: Tue, 03 Jul 2018 21:28:14 -0400

On Wed, 4 Jul 2018, at 9:30 AM, Andri Möll wrote:
> While I don't think use of durations in years or months are that
      common, I can definitely see value in them for events like "an
      entire month every n months". If there's ever a time to fix old
      mistakes, now would be the time, wouldn't it? Switching from
      duration format *based on* ISO 8601 to ISO 8601 proper would
      be a rather mild change after all.

No, strongly disagree. This makes implementation *much* harder, as the duration may now have a dependency on the start date rather than being a fixed value. Not to mention what does it even mean if you have a duration of 1 month starting 12pm on 31st May. June doesn't have 31 days, so is this to 30 June? Or to 1st July? What if it recurs? Adding significant complexity for dubious utility (and no way to translate into iCalendar) does not seem a good idea to me.

Neil.

---

From: Marten Gajda <[email-masked]>
Date: Wed, 4 Jul 2018 23:28:59 +0200

Am 04.07.2018 um 03:28 schrieb Neil Jenkins:
>> common, I can definitely see value in them for events like "an entire
>> month every n months". If there's ever a time to fix old mistakes,
>> now would be the time, wouldn't it? Switching from duration format
>> /based on/ ISO 8601 to ISO 8601 proper would be a rather mild change
>> after all.
>
> No, strongly disagree. This makes implementation /much/ harder, as the
> duration may now have a dependency on the start date rather than being
> a fixed value. Not to mention what does it even mean if you have a
> duration of 1 month starting 12pm on 31st May. June doesn't have 31
> days, so is this to 30 June? Or to 1st July? What if it recurs? Adding
> significant complexity for dubious utility (and no way to translate
> into iCalendar) does not seem a good idea to me.
I agree with Neil. ISO 8601 also allows things like "P0.5Y". How long is
P0.5Y? 182,5 days? 183 days? 182,621095 days? 6 months? Does its
duration depend on which day you start?

This doesn't even touch issues with calendar scales other than
Gregorian. How would you express the duration of a month in the Hebrew
calendar?

Week durations don't really add any value IMO. Conversion from/to days
is trivial and without any loss of information and many tools probably
convert weeks automatically to 7 days internally.

Marten

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: [email-masked]

Managing Director: Marten Gajda
Registered address: Dresden
Registered No.: AG Dresden HRB 34881
VAT Reg. No.: DE303248743

---

From: Andri Möll <[email-masked]>
Date: Wed, 4 Jul 2018 22:14:46 +0000

> a fixed value. 
Fair argument that it's not as simple as I might've made it out to be, 
but I'd push back a little on where the difficulty lies. Coming to an 
agreement, for sure, but implementing clamping to the end of the 
previous month in your example is two trivial expressions.

> What if it recurs?
Recursion is irrelevant as instances are based on the start date/time.

> dependency on the start date rather than being a fixed value.
That's a good argument, however I see two counters to that. First, fixed 
value in units of what? iCalendar+jsCalendar support two 
non-interchangable units of duration already --- one nominal, one 
accurate. P1M is as fixed as P1D, just in a different frame. Second, by 
the current jsCalendar spec, P1D seems to be allowed for an event with 
time. If it is to remain, its accurate length is also dependent on the 
start time due to DST. It too would need consensus on how to do time 
arithmetic with a nominal duration.

> ISO 8601 also allows things like "P0.5Y". How long is P0.5Y? 182,5 
> days? 183 days? 182,621095 days? 6 months?
Ah, I've forgotten it had fractional lengths. Yeah, I don't think their 
inclusion was particularly good. However, given your example and the 
fact ISO 8601 has only 3 atoms --- months, days and seconds --- 0.5Y 
translates to 6 months.

> Gregorian. How would you express the duration of a month in the Hebrew 
My knowledge beyond Gregorian is lacking at the moment, but presumably 
someone's already thought of it given we have RRULE with MONTHLY. Even 
if the conclusion was to forbid. :)

On 07/04/2018 09:28 PM, Marten Gajda wrote:
>>> duration format /based on/ ISO 8601 to ISO 8601 proper would be a 
>>> rather mild change after all.
>>
>> No, strongly disagree. This makes implementation /much/ harder, as 
>> the duration may now have a dependency on the start date rather than 
>> being a fixed value. Not to mention what does it even mean if you 
>> have a duration of 1 month starting 12pm on 31st May. June doesn't 
>> have 31 days, so is this to 30 June? Or to 1st July? What if it 
>> recurs? Adding significant complexity for dubious utility (and no way 
>> to translate into iCalendar) does not seem a good idea to me.
> I agree with Neil. ISO 8601 also allows things like "P0.5Y". How long 
> is P0.5Y? 182,5 days? 183 days? 182,621095 days? 6 months? Does its

---

From: Marten Gajda <[email-masked]>
Date: Thu, 5 Jul 2018 01:01:42 +0200

> Ah, I've forgotten it had fractional lengths. Yeah, I don't think
> their inclusion was particularly good. However, given your example and
> the fact ISO 8601 has only 3 atoms --- months, days and seconds ---
> 0.5Y translates to 6 months. 
You mean the same way P0.5D translates to 12 hours? Or P0.5M translates
to 15 days or 15.5 days?

How about P0.1Y or even P0.0001Y ?
>> Gregorian. How would you express the duration of a month in the
>> Hebrew calendar?
Right, for RRULE there is RSCALE, which essentially let's you do the
math in the other calendar scale. So a Hebrew Year has 12 months, 13 in
a leap year (each 29 or 30 days long). How much is P0.5Y in a Hebrew
leap year?

>>> recurs? Adding significant complexity for dubious utility (and no
>>> way to translate into iCalendar) does not seem a good idea to me.
>> Gregorian. How would you express the duration of a month in the
>> Hebrew calendar?
>>
>> Week durations don't really add any value IMO. Conversion from/to
>> days is trivial and without any loss of information and many tools
>> probably convert weeks automatically to 7 days internally.
>>
>> Marten
>>>
>>> Neil.
>>>
>
>

-- 
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

phone: +49 177 4427167
email: [email-masked]

---

From: Neil Jenkins <[email-masked]>
Date: Wed, 04 Jul 2018 19:10:29 -0400

On Thu, 5 Jul 2018, at 8:15 AM, Andri Möll wrote: 
> Second, by the current jsCalendar spec, P1D seems to be allowed
      for an event with time. If it is to remain, its accurate length is
      also dependent on the start time due to DST. It too would need
      consensus on how to do time arithmetic with a nominal duration.

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.

Neil.

---

From: Ronald Tse <[email-masked]>
Date: Thu, 5 Jul 2018 00:16:12 +0000

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. There will be a note on this in the new ISO 8601-1. The “second” unit doesn’t change in duration because it is defined as so by UTC/UT1 and the leap second mechanism.

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.

The decimal fraction notation in 8601 is “optional”. There’s no need to support that while staying compliant with ISO 8601.

Question: There is obviously an issue where the target day is not always available, such a P1Y starting on a leap day or P1M from February 29th. This behavior is not currently defined in ISO 8601, but we could propose. What is your view?

P.S to Andri: the new ISO 8601-2 defines a “profile” where a specification can selectively pick features of ISO 8601 to support, so the phrase “based on 8601” can be called a “profile of 8601”.

_____________________________________

Ronald Tse
Ribose Inc.

On Jul 5, 2018, at 7:10 AM, Neil Jenkins <[email-masked]<mailto:[email-masked]>> wrote:

dependency on the start date rather than
       being a fixed value.

*

*

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

---

From: Andri Möll <[email-masked]>
Date: Thu, 5 Jul 2018 00:17:50 +0000

On 07/04/2018 11:10 PM, Neil Jenkins wrote:
>> Second, by the current jsCalendar spec, P1D seems to be allowed for 
>> an event with time. If it is to remain, its accurate length is also 
>> dependent on the start time due to DST. It too would need consensus 
>> on how to do time arithmetic with a nominal duration.
>
> 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).
>
Doh, I entirely missed the reference to DST there. Thanks! This in turn 
makes me question two things:

1. What was the reasoning behind tying duration to UTC times? I find it 
odd given good practices of handling events are focusing on and storing 
time zones and storing local times over UTC because time zones aren't 
static. If I had an event with time lasting P5D, overlapping the DST 
switch (an overlap I couldn't foresee, perhaps, because my government 
makes decisions in the last minute), I would expect it to start and end 
on the same time of day. If I meant 5*24H, I would've used PT120H.

2. My reading of ISO 8601 back in the day was that it differentiated 
between nominal and accurate durations quite clearly:

> 2.1.7
> nominal duration
> duration expressed amongst others in years, months, weeks or days
> NOTE The duration of a calendar year, a calendar month, a calendar 
> week or a calendar day depends on its position in the calendar. 
> Therefore, the exact duration of a nominal duration can only be 
> evaluated if the duration of the calendar years, calendar months, 
> calendar weeks or calendar days used are known.
Even if my proposal of including years and months doesn't get through, I 
don't think promoting or perhaps even permitting nominal durations for 
events with times is a good idea if there's a hidden assumption that P1D 
== PT24H (because arithmetic is to be done on the UTC time). I'm willing 
to bet there are going to be plenty of implementations that will tick 
time forward linearly given an accurate duration (stepping over DST 
moments fine), but do arithmetic on local times given nominal durations, 
and then there will be discrepancies in end times.

---

From: Andri Möll <[email-masked]>
Date: Thu, 5 Jul 2018 00:17:52 +0000

On 07/04/2018 11:01 PM, Marten Gajda wrote:

>> My knowledge beyond Gregorian is lacking at the moment, but 
>> presumably someone's already thought of it given we have RRULE with 
>> MONTHLY. Even if the conclusion was to forbid. :)
>
> math in the other calendar scale. So a Hebrew Year has 12 months, 13 
> in a leap year (each 29 or 30 days long). How much is P0.5Y in a 
> Hebrew leap year?
Ah, if Hebrew years aren't a static product of Hebrew months, then years 
would have to become an atom as well. Coming back to your original point 
of fractional nominal durations, I checked ISO 8601 and I couldn't find 
it permitting fractions in anything other than seconds (and by overflow, 
other time components). Where did you get P0.5Y being a thing?

>> their inclusion was particularly good. However, given your example 
>> and the fact ISO 8601 has only 3 atoms --- months, days and seconds 
>> --- 0.5Y translates to 6 months.
>
> You mean the same way P0.5D translates to 12 hours? Or P0.5M 
> translates to 15 days or 15.5 days?
My initial reasoning and translation was based on the Gregorian calendar 
where there are indeed only 3 factors (months, days and seconds). Years 
are a product of months. Hours and minutes of seconds. Now, as said 
above, P0.5D doesn't seem to exist as I wished it didn't. :)

---

From: Ronald Tse <[email-masked]>
Date: Thu, 5 Jul 2018 00:40:48 +0000

Andri,

2. My reading of ISO 8601 back in the day was that it differentiated between nominal and accurate durations quite clearly:

The term “nominal duration” has been removed in the new ISO 8601-1.

Ah, if Hebrew years aren't a static product of Hebrew months, then years would have to become an atom as well. Coming back to your original point of fractional nominal durations, I checked ISO 8601 and I couldn't find it permitting fractions in anything other than seconds (and by overflow, other time components). Where did you get P0.5Y being a thing?

The new ISO 8601-1 will support P0.5Y.

Unfortunately the document is pay-walled but you can find it here: https://www.iso.org/standard/70907.html

Ronald Tse
Ribose Inc.

On Jul 5, 2018, at 8:17 AM, Andri Möll <[email-masked]<mailto:[email-masked]>> wrote:

On 07/04/2018 11:10 PM, Neil Jenkins wrote:
On Thu, 5 Jul 2018, at 8:15 AM, Andri Möll wrote:
dependency on the start date rather than being a fixed value.
Second, by the current jsCalendar spec, P1D seems to be allowed for an event with time. If it is to remain, its accurate length is also dependent on the start time due to DST. It too would need consensus on how to do time arithmetic with a nominal duration.

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

Neil.

Doh, I entirely missed the reference to DST there. Thanks! This in turn makes me question two things:

1. What was the reasoning behind tying duration to UTC times? I find it odd given good practices of handling events are focusing on and storing time zones and storing local times over UTC because time zones aren't static. If I had an event with time lasting P5D, overlapping the DST switch (an overlap I couldn't foresee, perhaps, because my government makes decisions in the last minute), I would expect it to start and end on the same time of day. If I meant 5*24H, I would've used PT120H.

2.1.7
nominal duration
duration expressed amongst others in years, months, weeks or days
NOTE The duration of a calendar year, a calendar month, a calendar week or a calendar day depends on its position in the calendar. Therefore, the exact duration of a nominal duration can only be evaluated if the duration of the calendar years, calendar months, calendar weeks or calendar days used are known.
Even if my proposal of including years and months doesn't get through, I don't think promoting or perhaps even permitting nominal durations for events with times is a good idea if there's a hidden assumption that P1D == PT24H (because arithmetic is to be done on the UTC time). I'm willing to bet there are going to be plenty of implementations that will tick time forward linearly given an accurate duration (stepping over DST moments fine), but do arithmetic on local times given nominal durations, and then there will be discrepancies in end times.
_______________________________________________
calsify mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/calsify

---

From: Neil Jenkins <[email-masked]>
Date: Wed, 04 Jul 2018 20:47:49 -0400

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.

---

From: Ronald Tse <[email-masked]>
Date: Thu, 5 Jul 2018 00:52:18 +0000

Simplicity is certainly preferred, but the leap second is already part of RFC 5545.

Ronald Tse
Ribose Inc.

On Jul 5, 2018, at 8:47 AM, Neil Jenkins <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Neil Jenkins <[email-masked]>
Date: Wed, 04 Jul 2018 20:56:35 -0400

> Simplicity is certainly preferred, but the leap second is already part of RFC 5545. 

Sure, but the spec allows it not to be supported, and it can trivially be ignored without any real world compatibility issues. The same could not be said for durations of "1 month".

Neil.