Subject: [calsify] JSCalendar: fractional seconds

From: "Robert Stepanek" <[email-masked]>
Date: Thu, 06 Jun 2019 12:49:40 +0100

It just occurred to me that the current JSCalendar RFC draft ambiguously defines if fractional seconds are allowed in the LocalDate time type.

To be clear: we intend to allow fractional seconds in the start property (and any other LocalDate property). The next version of the RFC draft will define this more clearly.

Unfortunately, fractional second date-times and durations can not be round-tripped out of the box with iCalendar. We will define an iCalendar extension parameter in the informational guide for mapping iCalendar and JSCalendar (draft-ietf-calext-jscalendar-icalendar):
 * X-FRACSEC of value type INTEGER
 * This parameter MAY be set on iCalendar properties of type DATE-TIME or DURATION. It MUST NOT be set more than once per property.
 * The value of this parameter defines the fractional seconds of the DATE-TIME or DURATION type.
 * This will allow iCalendar implementations not being aware of this extension parameter to display the time value "good enough" with second precision.

Please let me know if you prefer another approach.

Cheers,
Robert

---

From: Marten Gajda <[email-masked]>
Date: Thu, 6 Jun 2019 14:03:56 +0200

Is this parameter is meant to preserve the fractional seconds for
round-trips or are iCalendar clients encouraged to use the value?

I mean, would a client that's aware of X-FRACSEC have to match
RECURRENCE-IDs ,RDATES and EXDATES taking the fractional seconds into
account?

I think we should advise against that and make clear that this is not
meant to increase the precision of times in iCalendar, but merely to
preserve it.

Btw, how do we cope with unaware clients doing partial updates? I.e. a
client which is not aware of X-FRACSEC adds a new recurrence-override
(not adding X-FRACSEC to RECURRENCE-ID). When being converted back to
JSCalendar, this would result in an additional instance instead of an
override.

Marten

Am 06.06.19 um 13:49 schrieb Robert Stepanek:
> It just occurred to me that the current JSCalendar RFC draft
> ambiguously defines if fractional seconds are allowed in the LocalDate
> time type.
>
> To be clear: we intend to allow fractional seconds in the start
> property (and any other LocalDate property). The next version of the
> RFC draft will define this more clearly.
>
> Unfortunately, fractional second date-times and durations can not be
> round-tripped out of the box with iCalendar. We will define an
> iCalendar extension parameter in the informational guide for mapping
> iCalendar and JSCalendar (draft-ietf-calext-jscalendar-icalendar):
>
>   * This parameter MAY be set on iCalendar properties of type
>     DATE-TIME or DURATION. It MUST NOT be set more than once per property.
>   * This will allow iCalendar implementations  not being aware of this
>     extension parameter to display the time value "good enough" with
>     second precision.
>
>
> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify

-- 
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: "Robert Stepanek" <[email-masked]>
Date: Thu, 06 Jun 2019 13:04:19 +0100

On second thought, I'll change the X-FRACSEC name to FRACSEC and its parameter type to FLOAT:

So 

>  * X-FRACSEC of value type INTEGER

will be changed to

FRACSEC of type FLOAT, where the float value MUST be positive and MUST have an integral part of 0.

Cheers,
Robert

---

From: "Robert Stepanek" <[email-masked]>
Date: Thu, 06 Jun 2019 13:07:08 +0100

On Thu, Jun 6, 2019, at 1:04 PM, Marten Gajda wrote:
> I think we should advise against that and make clear that this is not meant to increase the precision of times in iCalendar, but merely to preserve it.

Agreed.

> Btw, how do we cope with unaware clients doing partial updates? I.e. a client which is not aware of X-FRACSEC adds a new recurrence-override (not adding X-FRACSEC to RECURRENCE-ID). When being converted back to JSCalendar, this would result in an additional instance instead of an override

I'd say the JSCalendar implementation should leniently treat this as an override.

---

From: "Ken Murchison" <[email-masked]>
Date: Thu, 06 Jun 2019 08:55:56 -0400

As a related topic, a libical user/developer submitted a PR to add millisecond precision to time values. I haven’t committed it because it simply changes the DATETIME values which certainly isn’t backwards compatible. I suggested a new VALUE type but even that isn’t compatible with unaware clients. 

Regardless, there does appear to be *some* desire to have fractional seconds support in iCalendar. 

--
Kenneth Murchison
Cyrus Development Team
FastMail US LLC
[email-masked]

On Thu, Jun 6, 2019, at 8:04 AM, Marten Gajda wrote:
> Is this parameter is meant to preserve the fractional seconds for round-trips or are iCalendar clients encouraged to use the value?

> I mean, would a client that's aware of X-FRACSEC have to match RECURRENCE-IDs ,RDATES and EXDATES taking the fractional seconds into account? 

> Btw, how do we cope with unaware clients doing partial updates? I.e. a client which is not aware of X-FRACSEC adds a new recurrence-override (not adding X-FRACSEC to RECURRENCE-ID). When being converted back to JSCalendar, this would result in an additional instance instead of an override.

calsify mailing list
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

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

---

From: "Robert Stepanek" <[email-masked]>
Date: Thu, 06 Jun 2019 14:07:30 +0100

This is a draft specification, happy about any input:

2.1. FRACSEC parameter

 Parameter name: FRACSEC

 Purpose: This parameter is used to define fractional seconds for
 time values and durations. It is meant to preserve time precision
 on time values and duration with sub-second precision, without
 increasing the time value range within iCalendar.

 Description: This parameter MAY be specified on properties of type
 DATE-TIME or DURATION. The integral part of the float value MUST
 be zero. The value MUST NOT be negative. iCalendar
 implementations MAY ignore this parameter in date time arithmetic.
 Implementations MUST ignore presence of the FRACSEC parameter on
 RECURRENCE-ID properties when determining recurrence overrides.
 If present on a RECURRENCE-ID property, its value MUST match the
 FRACSEC parameter value on the DTSTART property.

 Format Definition:

 This parameter is defined by the following notation:

 fracsec-param = float

 Example: DTSTART;FRACSEC=0.03:20190605T133015

calsify mailing list
Marten Gajda
CEO

dmfs GmbH
Schandauer Straße 34
01309 Dresden
GERMANY

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

---

From: Ken Murchison <[email-masked]>
Date: Mon, 10 Jun 2019 12:16:37 -0400

Would it make sense to change the parameter name to SUBSECOND as its a 
known term?

This also would allow extending recurrence rules to have a matching 
SUBSECONDLY frequency if needed.  As stated early in the thread, a 
libical user wants to extend RRULE to do exactly this.

On 6/6/19 9:07 AM, Robert Stepanek wrote:
>    Example:  DTSTART;FRACSEC=0..03:20190605T133015
>
>
>
>> As a related topic, a libical user/developer submitted a PR to add 
>> millisecond precision to time values. I haven’t committed it because 
>> it simply changes the DATETIME values which certainly isn’t backwards 
>> compatible. I suggested a new VALUE type but even that isn’t 
>> compatible with unaware clients.
>>
>>> RECURRENCE-IDs ,RDATES and EXDATES taking the fractional seconds 
>>> into account?
>>>
>>> I think we should advise against that and make clear that this is 
>>> not meant to increase the precision of times in iCalendar, but 
>>> merely to preserve it.
>>>
>>> Btw, how do we cope with unaware clients doing partial updates? I.e. 
>>> a client which is not aware of X-FRACSEC adds a new 
>>> recurrence-override (not adding X-FRACSEC to RECURRENCE-ID). When 
>>> being converted back to JSCalendar, this would result in an 
>>> additional instance instead of an override.
>>>
>>> Marten
>>>
>>>> ambiguously defines if fractional seconds are allowed in the 
>>>> LocalDate time type.
>>>>
>>>> property (and any other LocalDate property). The next version of 
>>>> the RFC draft will define this more clearly.
>>>>
>>>> Unfortunately, fractional second date-times and durations can not 
>>>> be round-tripped out of the box with iCalendar. We will define an 
>>>> iCalendar extension parameter in the informational guide for 
>>>> mapping iCalendar and JSCalendar 
>>>> (draft-ietf-calext-jscalendar-icalendar):
>>>>
>>>>   * This will allow iCalendar implementations  not being aware of
>>>>     this extension parameter to display the time value "good
>>>>     enough" with second precision.
>>>>
>>>>
>>>> [email-masked]  <mailto:[email-masked]>
>>> email:[email-masked]  <mailto:[email-masked]>
>>>

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Ken Murchison <[email-masked]>
Date: Mon, 10 Jun 2019 12:23:40 -0400

> libical user wants to extend RRULE to do exactly this.
Hmm, but since INTERVAL is an integer, we would have to specify the 
scale for subseconds (milli, micro, pico, nano?)  Or we allow 
MILLISECONDLY, etc as frequencies.

>>> it simply changes the DATETIME values which certainly isn’t 
>>> backwards compatible. I suggested a new VALUE type but even that 
>>> isn’t compatible with unaware clients.
>>>
>>>> Btw, how do we cope with unaware clients doing partial updates? 
>>>> I.e. a client which is not aware of X-FRACSEC adds a new 

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: "Robert Stepanek" <[email-masked]>
Date: Mon, 17 Jun 2019 16:40:02 +0200

On Mon, Jun 10, 2019, at 6:16 PM, Ken Murchison wrote:
> Would it make sense to change the parameter name to SUBSECOND as its a known term? 

I think that's a better than name than FRACSEC. I'll use it.

Thanks.