Subject: [Ietf-calsify] Bare Naked VEVENT

From: jwn2 at qualcomm.com (John W Noerenberg II)
Date: Thu Jul 21 14:46:52 2005

Maybe I'm too stupid but I'm unclear on the interpretation of a 
collection of iCalendar objects.

Recently, I've been experimenting with collections of iCalendar that 
describe events, etc, and reading Chris' update on 2445 (Nice work, 
btw).

There's a certain, well-known, widely-used scheduling application 
that chokes if an iCalendar specification containing a VEVENT lacks a 
VTIMEZONE.  As far as I can tell from 2445 (or 2445bis) a VEVENT 
doesn't require the presence of a VTIMEZONE, but it is not definitive.

I've looked through my archives of CalSch and Calsify, but no one 
seems to have discussed this.

Is there consensus on this or did this come up in the interop testing 
to date and I've missed it?

Thanks!
-- 

john noerenberg
   ----------------------------------------------------------------------
   Statt des t?richten Ignorabimus hei?e im Gegenteil unsere L?sung:
   Wir m?ssen wissen, Wir werden wissen.
   -- David Hilbert, "Logic and the Understanding of Nature, Sep 1930
   ----------------------------------------------------------------------

---

From: Doug at Royer.com (Doug Royer)
Date: Thu Jul 21 15:02:08 2005

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050721/24407abd/smime.bin

---

From: jwn2 at qualcomm.com (John W Noerenberg II)
Date: Thu Jul 21 16:16:53 2005

At 4:01 PM -0600 7/21/05, Doug Royer wrote:
>If an entry is tied to a time zone, a TZID and an associated 
>VTIMEZONE MUST BE included.  DTSTART;TZID=PST;20050101T000000 starts 
>at midnight New Years Day in the PST time zone and a PST VTIMEZONE 
>MUST BE included.
>
>So a VTIMEZONE is only supplied when any DATE or DATE-TIME
>value includes a TZID parameter. [or as Robert notes below... - jwn2]

Ah.  Very clear, Doug.  Thank you!

>
>And yes, some vendors are not 2445/2446/2447 compliant.

I'm shocked.  Shocked! :-)

At 6:03 PM -0400 7/21/05, [email-masked] wrote:
>4.6.5 Time Zone Component
>The "VTIMEZONE" calendar component MUST be present if the iCalendar
>   object contains an RRULE that generates dates on both sides of a time
>   zone shift

Yes, this is true.  I didn't make myself clear.  If an iCalendar 
object contains no VEVENT, VTODO, or VJOURNAL components that 
includes an RRULE, then a VTIMEZONE object isn't required.  But what 
about an object with an RDATE that spans a time zone shift?  Better 
here would be:

[Line 1758 of 2445bis]:	...contains an RRULE or RDATE that generates....

EXDATEs and EXRULEs con only occur if there's a recurrence rule, so 
perhaps there's no need to mention them.

-- 

john noerenberg
[email-masked]
   ----------------------------------------------------------------------
   Like the Sorcerer's Apprentice, we succeeded beyond our
   wildest dreams and our worst fears.
   -- Steve Crocker, quoted in Wired Magazine, Apr, 1999
   ----------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050721/7f24280f/attachment.html

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Thu Jul 21 16:34:11 2005

> >   object contains an RRULE that generates dates on both sides of a time

Actually, this is not really correct. If the DTSTART is a DATE value (i.e. no 
time attached), the TZID is not necessary (so it's not dates on both sides, 
but rather times on both sides).

Also notice that if DTSTART is given in UTC, there are no time zone shifts, so 
a VTIMEZONE doesn't have to be present in that case.

> about an object with an RDATE that spans a time zone shift?  

Depends on which format you use for the RDATE. Again, the three different ways 
to represent times in iCalendar (as described by Doug) come into play. Only 
if the RDATE is relative to a time zone, then the VTIMEZONE is important.

Cheers,
Reinhold

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at
 * K Desktop Environment, http://www.kde.org/, KOrganizer / KPilot maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050722/3abe1ec1/attachment-0001.pgp

---

From: Doug at Royer.com (Doug Royer)
Date: Thu Jul 21 17:27:27 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050721/f7008c97/smime.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Thu Jul 21 17:30:04 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050721/52d8f605/smime.bin

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Mon Jul 25 06:05:17 2005

On Friday 22 July 2005 02:27, Doug Royer wrote:
> Reinhold Kainhofer wrote:
> And that single sentence goes on to say "...  (e.g. both in
> Standard Time and Daylight Saving Time) unless the iCalendar
> object intends to convey a floating time (See the
> section "4.1.10.11 Time" for proper interpretation of floating time).

Oops, I blame my carelessness on the time (1:30 am...).

> > Actually, this is not really correct. If the DTSTART is a DATE value
> > (i.e. no time attached), the TZID is not necessary (so it's not dates on
> > both sides, but rather times on both sides).
>
> I do not think that a DATE or DATE-TIME value is what makes TZID
> optional.

Reading up a bit on the old mailing list archive, it came up every now and 
then that an event with only a DATE value is really meant as whole day, 
without a time associated. See e.g. your own post:
http://www.imc.org/ietf-calendar/archive1/msg03650.html

But yes, that's only one aspect.:

> So if you want it relative to a TZID, specify 
> a TZID and include a VTIMEZONE, else specify it in UTC which has
> no time zone shifts, or floating in which case it can be variable length
> (as seen by the wall clock to the observer).

Right, DATE events seem to need the same settings as timed events. Thanks for 
pointing this out. All three situations (UTC, relative to TZID or floating) 
also make sense for DATE events...

Cheers,
Reinhold

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050725/2df93de3/attachment.pgp