Re: [calsify] JSCalendar: alternative to current all-day events
Marten Gajda <marten@dmfs.org> Mon, 17 June 2019 22:04 UTC
Return-Path: <marten@dmfs.org>
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 2E6541202F1 for <calsify@ietfa.amsl.com>; Mon, 17 Jun 2019 15:04:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dmfs.org
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 Eif3mYCi110a for <calsify@ietfa.amsl.com>; Mon, 17 Jun 2019 15:04:16 -0700 (PDT)
Received: from mailrelay3-1.pub.mailoutpod1-cph3.one.com (mailrelay3-1.pub.mailoutpod1-cph3.one.com [46.30.210.184]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C9ED12004D for <calsify@ietf.org>; Mon, 17 Jun 2019 15:04:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dmfs.org; s=20140924; h=content-type:in-reply-to:mime-version:date:message-id:from:references:to: subject:from; bh=+Iy48D/oavXFHTfRIjVL1G61IyCno+m0z7b61RbExME=; b=fIr8UNi6jHjgDZE1LURk/lkoQjdepiqlrHCNaXQNWuYYB1IoxkopEoq6a4S8cxSH6pdNzU4LKkajm NZZwNspCyHAe1QtDYkYEDkxUcmMLM/WzBiMUOnh7bT/s1DdyAJFjVAgshbNiqiQ6qV9fAh/lpfLP1o iV4vxrtHXhk+6jdc=
X-HalOne-Cookie: 0775b3919b2e773786c01fab9fa68bb83d9e1a49
X-HalOne-ID: d692aac5-914b-11e9-a0e4-d0431ea8bb03
Received: from smtp.dmfs.org (unknown [84.129.207.176]) by mailrelay3.pub.mailoutpod1-cph3.one.com (Halon) with ESMTPSA id d692aac5-914b-11e9-a0e4-d0431ea8bb03; Mon, 17 Jun 2019 22:04:12 +0000 (UTC)
Received: from boss.localdomain (p548B1ED8.dip0.t-ipconnect.de [84.139.30.216]) by smtp.dmfs.org (Postfix) with ESMTPSA id C53B629B for <calsify@ietf.org>; Tue, 18 Jun 2019 00:04:11 +0200 (CEST)
To: calsify@ietf.org
References: <7ec4462f-9e69-409e-9925-6f0beae7424c@www.fastmail.com> <8591f785-e075-4e71-b1ef-b30afe11aa5a@www.fastmail.com>
From: Marten Gajda <marten@dmfs.org>
Message-ID: <b2968423-c5cf-f9e9-70b4-d02a704655bb@dmfs.org>
Date: Tue, 18 Jun 2019 00:04:11 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <8591f785-e075-4e71-b1ef-b30afe11aa5a@www.fastmail.com>
Content-Type: multipart/alternative; boundary="------------512DF6065737B46D56F58912"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/calsify/wy-rDHYiCfnvfcxmA_jCuzMbSok>
Subject: Re: [calsify] JSCalendar: alternative to current all-day events
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: Mon, 17 Jun 2019 22:04:19 -0000
Am 17.06.19 um 18:14 schrieb Robert Stepanek: > I also removed the "isAllDay" property entirely from the JSTask object. Hmm ... I see how "isAllDay" doesn't really apply to a task, but it would be nice to have a way to express this kind of fussiness for start and/or due dates in cases when the actual time is not that important (or even unknown). Always terminating tasks on a specific time can give a false sense of accuracy which might not exist. Sometimes you just want to express "at some time throughout that day". Does that make sense? Marten > > See > https://tools.ietf.org/html/draft-ietf-calext-jscalendar-15#section-5.1.4 > > From my initial analysis, the mapping to iCalendar is rather simple: > > * If the JSEvent timeZone is null, the start time has zero time, and > the duration is a multiple of days or weeks, then DTSTART is of > type DATE. In this case, clip off any non-zero time from the > recurrence rule "until" property. > * Otherwise map "start" to a DTSTART of type DATE-TIME. > * I also consider using a new iCalendar boolean property IS-ALL-DAY > to cleanly map "isAllDay". > > > I will update the informational iCalendar mapping guideline accordingly. > > Cheers, > Robert > > On Thu, Jun 6, 2019, at 5:56 PM, Robert Stepanek wrote: >> One of the repeatedly discussed topics in JSCalendar is how to model >> all-day events. >> >> Specifically, variants of the following uses repeatedly come up, >> where the current JSCalendar model seems not to be adequate: >> >> * Calendar users create an event starting e.g. 8am and ending 7pm, >> but want to view this an all-day event in their UI. The current >> model misses a flag to express this, as the isAllDay property is >> not appropriate to indicate the user intention. >> * Calendar users want to set their calendar on their birthday, when >> they only would like to set it for the complete day in their >> usual time zone. They still want it to show up as an all-day >> event in their UI. >> >> >> In both cases, developers thought to use the isAllDay property to >> express a user intention, but came they learn they couldn't. >> >> This is reason enough to revisit that part of the specification and >> discuss alternatives. >> >> *Currently*: >> >> * Any event MUST define a start property value in the form >> "YYYY-MM-DDTHH:MM:SS[.DIGITS]" >> * An all-day event: >> o MUST have the isAllDay property set to "true" >> o MUST NOT have a non-zero time in the start and duration >> property values >> o MUST NOT define a time zone >> * Any other event: >> o MUST have the isAllDay property set to "false" >> o MAY define non-zero time in start, duration >> o MAY set a timeZone. >> * This allows to model iCalendar DATE, local DATE-TIME, floating >> DATE-TIME, UTC DATE-TIME. >> >> >> *Alternative*: >> >> * The isAllDay boolean property gets removed. >> * A new showAsAllDay boolean defines how the user intends to view >> this event. Setting this property does not have any implications >> on the allowed values in the event time properties. >> * The start, duration, timeZone properties and their recurrence >> overrides can all can be defined independently. The >> recurrenceRule{until} property also can be defined independently. >> * It is up to implementations to convert this time model to >> iCalendar. Most probably: >> o an event with zero time in start, duration, until and no time >> zone will be converted DATE value types >> o an event with no time zone will be converted to a local >> DATE-TIME without TZID >> o otherwise it will be a DATE-TIME with TZID or UTC DATE-TIME >> >> >> What do you think? Did we miss something? >> >> Cheers, >> Robert >> >> >> >> >> >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify >> > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- Marten Gajda CEO dmfs GmbH Schandauer Straße 34 01309 Dresden GERMANY phone: +49 177 4427167 email: marten@dmfs.org Managing Director: Marten Gajda Registered address: Dresden Registered No.: AG Dresden HRB 34881 VAT Reg. No.: DE303248743
- [calsify] JSCalendar: alternative to current all-… Robert Stepanek
- Re: [calsify] JSCalendar: alternative to current … Robert Stepanek
- Re: [calsify] JSCalendar: alternative to current … Daniel Migault
- Re: [calsify] JSCalendar: alternative to current … Robert Stepanek
- Re: [calsify] JSCalendar: alternative to current … Andri Möll
- Re: [calsify] JSCalendar: alternative to current … Marten Gajda
- Re: [calsify] JSCalendar: alternative to current … Marten Gajda
- Re: [calsify] JSCalendar: alternative to current … Doug Royer
- Re: [calsify] JSCalendar: alternative to current … Doug Royer
- Re: [calsify] JSCalendar: alternative to current … Bron Gondwana
- Re: [calsify] JSCalendar: alternative to current … Neil Jenkins
- Re: [calsify] JSCalendar: alternative to current … Robert Stepanek
- Re: [calsify] JSCalendar: alternative to current … Doug Royer
- Re: [calsify] JSCalendar: alternative to current … Michael Douglass
- Re: [calsify] JSCalendar: alternative to current … Doug Royer
- Re: [calsify] JSCalendar: alternative to current … Bron Gondwana
- Re: [calsify] JSCalendar: alternative to current … Neil Jenkins
- Re: [calsify] JSCalendar: alternative to current … Doug Royer
- Re: [calsify] JSCalendar: alternative to current … Doug Royer
- Re: [calsify] JSCalendar: alternative to current … Robert Stepanek
- Re: [calsify] JSCalendar: alternative to current … Cyrus Daboo
- Re: [calsify] JSCalendar: alternative to current … Doug Royer
- Re: [calsify] JSCalendar: alternative to current … Michael H Deckers
- Re: [calsify] JSCalendar: alternative to current … Michael H Deckers
- Re: [calsify] JSCalendar: alternative to current … Michael Douglass
- Re: [calsify] JSCalendar: alternative to current … Doug Royer