Re: [calsify] JSCalendar: fractional seconds

Cyrus Daboo <cyrus@daboo.name> Thu, 06 June 2019 15:37 UTC

Return-Path: <cyrus@daboo.name>
X-Original-To: calsify@ietfa.amsl.com
Delivered-To: calsify@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00CC120124 for <calsify@ietfa.amsl.com>; Thu, 6 Jun 2019 08:37:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxwiO2eFg9XT for <calsify@ietfa.amsl.com>; Thu, 6 Jun 2019 08:37:44 -0700 (PDT)
Received: from daboo.name (daboo.name [173.13.55.49]) by ietfa.amsl.com (Postfix) with ESMTP id 18129120020 for <calsify@ietf.org>; Thu, 6 Jun 2019 08:37:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 8293B300B9F814; Thu, 6 Jun 2019 11:37:43 -0400 (EDT)
X-Virus-Scanned: amavisd-new at daboo.name
Received: from daboo.name ([127.0.0.1]) by localhost (daboo.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6_TlEkVBVQx; Thu, 6 Jun 2019 11:37:43 -0400 (EDT)
Received: from [172.16.111.68] (unknown [144.178.28.141]) by daboo.name (Postfix) with ESMTPSA id 9834A300B9F804; Thu, 6 Jun 2019 11:37:42 -0400 (EDT)
Date: Thu, 06 Jun 2019 08:37:40 -0700
From: Cyrus Daboo <cyrus@daboo.name>
To: Robert Stepanek <rsto@fastmailteam.com>, calsify@ietf.org
Message-ID: <2482E64E5B84338407DE3EB0@cyrus.local>
X-Mailer: Mulberry/4.1.0b1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size="2343"
Archived-At: <https://mailarchive.ietf.org/arch/msg/calsify/NeEjQivM2Akty3RPMkQn-bF9_VY>
Subject: Re: [calsify] JSCalendar: fractional seconds
X-BeenThere: calsify@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <calsify.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/calsify>, <mailto:calsify-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/calsify/>
List-Post: <mailto:calsify@ietf.org>
List-Help: <mailto:calsify-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/calsify>, <mailto:calsify-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Jun 2019 15:37:46 -0000

Hi Robert,
Some initial thoughts:

--On June 6, 2019 at 2:07:30 PM +0100 Robert Stepanek 
<rsto@fastmailteam.com> wrote:

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

I think we should have a strong statement here, something equivalent to:

    FRACSEC MUST NOT be used in date-time calculations or comparisons in 
iCalendar

On the other hand, if your intent is that it is used in such calculations, 
then you are going to need much more detailed language on how to handle 
cases where it is missing on things like RECURRENCE-ID, RDATE, EXDATE etc.


>  Description: This parameter MAY be specified on properties of type
>  DATE-TIME or DURATION. The integral part of the float value MUST

Can this also be used with value type TIME?

How will PERIOD be handled? Right now that is only used in iCalendar 
FREEBUSY and RDATE. Looks like JSCalendar does not support a "period" on 
its equivalent of RDATE (something that might need to be called out in the 
mapping document if not already there). Also, JSCalendar does not seem to 
support an equivalent to VFREEBUSY, which may be a big barrier to adoption 
by "enterprise" calendaring system which typically do use free busy a lot.

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

In components other than VEVENT, a DTSTART is not required to be present 
when RECURRENCE-ID is present (e.g. VTODO with just a DUE). So this should 
probably be re-worded, something like:

    its value MUST match the FRACSEC parameter value on the DATE-TIME
    property that defines the reference point for the recurring instances.

Should FRACSEC be allowed on an RRULE containing a DATE-TIME UNTIL value? 
Looks like JSCalendar allows fraction seconds on UNTIL.

Is there any need to use fraction seconds in an RRULE BY... rule? (I hope 
not).


-- 
Cyrus Daboo