Subject: CAP: why does a calendar have a TZID?

From: John Stracke <[email-masked]>
Date: Thu, 16 Aug 2001 14:35:48 -0400

CAP section 10.2 lists a TZID property for a calendar. What does this 
mean? Every DSTART, etc., in every VEVENT, etc., in the calendar has to 
specify its own TZID.

-- 
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |If God had meant us to be in the Army, we    |
[email-masked] <mailto:[email-masked]>|would've been born with green, baggy skin.   |
\==============================================================/

---

From: "David L. Nicol" <[email-masked]>
Date: Mon, 20 Aug 2001 19:46:14 -0500

> mean? Every DSTART, etc., in every VEVENT, etc., in the calendar has to

The time zone that the calendar lists times in.  It would also make sense
to
relax the time zone requirement for everything else and allow the TZID for
the calendar to be the default when not specified.

-- 
                                           David Nicol 816.235.1187
"... raised indoors and tested by certified technicians"

---

From: John Stracke <[email-masked]>
Date: Tue, 21 Aug 2001 11:12:35 -0400

David L. Nicol wrote:

>>mean?
>The time zone that the calendar lists times in.
>
But the calendar doesn't list times; it lists events (etc.), each of 
which has its own timezone(s).

>  It would also make sense
This would have the problem that the CUA would have to be very careful 
to add correct TZIDs and VTIMEZONEs when exposing data from the CS to 
any other entity.  We have a good self-contained data model; we 
shouldn't play games with it.

-- 
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Campbell's has it wrong--it's "Never         |
[email-masked]|underestimate the power of *chocolate*".     |
\==============================================================/

---

From: "David L. Nicol" <[email-masked]>
Date: Wed, 22 Aug 2001 15:47:10 -0500

John Stracke (and I) wrote:

> [ a variety of off-list back-and-forth ]

And then there's daylight savings time and all that.  It's a lot
easier to simply pretend that daylight savings time doesn't happen
and list events in local time than having all events switch between
two different time zones in the future.  

Although date math libraries will take care of translating to and
from GMT quite handily, so requiring one be embedded into a CUA
is no big thing.

The question is, is time zone transfer the responsibility of
the CS or is it the responsibility of the clients?

I would like to see some clearly defined but optional ways
for the CS to do it, so I can do a telnet session to a CS
and not have to express the times in GMT.  Expressing times
in GMT is a big PITA unless you've got BBC News on the radio
to give you some bearing on it.

---

From: John Stracke <[email-masked]>
Date: Wed, 22 Aug 2001 17:09:13 -0400

>two different time zones in the future.  
It's not two different timezones, it's one timezone with different 
observances.  Read RFC-2445.

>for the CS to do it, so I can do a telnet session to a CS
Kind of unlikely, unless your CS supports plaintext passwords.

>Expressing times
date -u

-- 
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"She gets kidnapped. He gets killed. But it  |
[email-masked]|turns out okay." -- _Princess Bride_ poster  |
\==============================================================/

---

From: "David L. Nicol" <[email-masked]>
Date: Wed, 22 Aug 2001 17:22:28 -0500

> observances.  Read RFC-2445.

No. CST and CDT are two timezones.  I don't care what the reference
says.  Half the year my clock is five hours behind london, half the
year its six. Vigo County, Indiana, is at GMT-5 all the time.

> Kind of unlikely, unless your CS supports plaintext passwords.

Why won't it?  My POP server supports plaintext passwords, so does
my IMAP server.  Selecting an appropriately secure authENTICATION
method is up to the client.

> >to give you some bearing on it.

And how many Windows boxes does that work on?  People are IDIOTS,
John.  We have to accomodate them.  Wanting to switch the CAP standard
from "every CS knows what timzone it uses by default and will tell
you if you ask it" to "every CS must use GMT to be compliant" stinks,
to my poorly read, non-compliant nose.

If I telnet to port five thousand whatever of the campus calendar server
to log in as anonymous and check on a class schedule, I would very much
like to have my plain text responses return to me in the local time,
including times on events that might have been loaded in from a different
time zone.

I haven't read the CalSch requirements document, but if "must be able to
support a workable but awkward plain text session, the way NNTP, SMTP,
POP, IMAP and so forth do" wasn't in there, it surely is missing due
to mere oversight.  Convince me different (that's right, convince me that
telnetability is deprecated and verbose commands are in there for no
reason at all) and I'll cheerfully abandon any hope of ever bringing 
the light of the truth of Authorization Certificates to this podunk,
backwater, braindead standards committee and furthermore I will reccommend
to whoever I can find that the lot of you be summarily shot.