Subject: Update of iCalendar Draft online.

From: Eric Busboom <[email-masked]>
Date: Mon, 4 Jun 2001 11:23:20 -0700 (PDT)

A new version of the iCalendar draft ( updates to RFC2445) is now online.

This version fixes many of the typos on the issues list, includes the new
BYSETPOS text, and is labeled as an internet draft instead of RFC2445.

I've also updates the issues list.

For details, see:

	http://softwarestudio.org/iCal/

eric.

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 5 Jun 2001 11:24:36 -0400 (EDT)

> 	http://softwarestudio.org/iCal/

Here are some suggestions for further clarifications.

In section 4.3.5, DATE-TIME: add at the end of the FORM #3 subsection,
before the leapsecond discussion:

     DATE-TIME values SHOULD NOT use the local timezone form if the
     resulting time would be ambiguous, due to clocks being set backward.
     For instance, TZID=US-Eastern;19971026T013000 can indicate both
     19971026T053000Z (if interpreted as U.S. Eastern Daylight Time) and
     19971026T063000Z (if interpreted as U.S. Eastern Standard Time).  When
     a local timezone form is ambiguous, the UTC representation SHOULD be
     used instead.  Applications which receive an ambiguous time MAY
     interpret them to mean any occurence of that time.

     DATE-TIME values MUST NOT indicate a nonexistent time in the local
     timezone.  For example, the time TZID=US-Eastern;19970406T023000 does
     not exist -- the second after TZID=US-Eastern;19970406T015959
     (U.S. Eastern Standard Time) is TZID=US-Eastern;19970406T030000
     (U.S. Eastern Daylight Time).

In section 4.3.10, Recurrence Rule:

Change :
       If BYxxx rule part values are found which are beyond the available
       scope (ie, BYMONTHDAY=30 in February), they are simply ignored.

To:
       If BYxxx rule part values are found which are outside the available
       scope for a given occurence of a rule (eg, BYMONTHDAY=30 for a rule
       which falls in February, or a time which falls in a leap-forward
       interval in the given timezone), that occurence is omitted.

(I think this was the consensus as to what this sentence means.)

After:
     Information, not contained in the rule, necessary to determine the
     various recurrence instance start time and dates are derived from the
     Start Time (DTSTART) entry attribute. For example,
     "FREQ=YEARLY;BYMONTH=1" doesn't specify a specific day within the month
     or a time. This information would be the same as what is specified for
     DTSTART.

Add:
     If the derived information is outside the appropriate scope for a given
     occurence of a rule (eg, the repetition of
     DTSTART=19970930;RRULE:FREQ=MONTHLY in February, or a time which falls
     in a leap-forward interval in the given timezone), that occurence
     is omitted.

(Clarifying that the same rule applies for derived information as for BYxxx
rules.)

Add, somewhere:
     If a repetition of a rule occurs at an ambiguous time (as defined in
     section 4.3.5, DATE-TIME) due to the time zone rule in effect, it is
     undefined whether the event occurs only at the first occurence of the
     ambiguous time, only at the second occurence of the ambiguous time, or
     at both occurences.  A rule author wishing to specify this explicitly
     SHOULD use explicit RDATE/EXDATE or yearly RRULE/EXRULE rules to
     clarify the intent.

Also, section 4.3.6 should incorporate whatever the consensus was of the
"Does 1 day == 24 hours?" thread, but I don't remember what that was.  Does
anyone have proposed text here?

-- 
Jonathan Lennox
[email-masked]