Subject: Re: Registration of text/calendar MIME property GEO_BOUNDS

From: [email-masked]
Date: Tue, 22 Aug 2000 22:12:11 -0400

I don't have a reference to these graphics standards anymore. They were 
left in a previous job(s). You should be able to find them in your 
neck-of-the-woods. UCSD was one of the great CG havens.

---

From: Chris Harris <[email-masked]>
Date: Thu, 24 Aug 2000 02:07:14 -0700 (PDT)

> I have not made an assertion that everyplace on earth
> has a time zone. I have no idea if it is true or false.

A point of intellectual curiosity - what time zone is the
North Pole in? Isn't it where they all meet? Does your time
zone then depend on which way you're facing?

c

__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/

---

From: [email-masked]
Date: Thu, 31 Aug 2000 11:52:35 -0400

Doug replied with:
>If the CUA knows its timezone name, but does not have
>the VTIMEZONE definition. Why not let the CUA choose?
>Example:
>
>                My mobile CUA thinks it's timezone is US/Pacific
>                because my OS says so.

When I stated "I am 95% against having the CUA doing the choosing by 
itself" I was considering the case where the CUA could be coded to use 
some OS knowledge but not every OS has it (MacOS lacks it; not sure about 
all Un*x's).  If you only plan on supporting Windows OS CUAs (or on OS's 
that do have some TZ knowledge) then the design is fine.  Otherwise, the 
CU and CUA should be working together instead of the CUA doing it possibly 
right, possibly wrong.

Lets pick a TZ that has exceptions, say Phoenix Arizona.  If your OS only 
has "US/Mountain" then your CUA will not properly be able to adjust for AZ 
that does not support DST.  For 6 months, your times will be wrong.  If 
you expect an OS that was coded 2 years ago to be fully updated w/all TZ 
changes that can occur after its writing then you are in for a support 
nightmare (ie: France changes the dates annually but I dont necessarily 
run the French version of the OS if Im a mobile user from the UK or 
Germany).

>So my mobile CUA
>                queries a CAP server and provides my GEO position.
>[Snip, snip]
>I can write a tool that selects the correct VTIMEZONE America/Los_Angles
>from a list.There are times when the CUA will know which to use.
>
>If it can't find a match - then the user selects.

Ugh, just how will your tool know that Phoenix is in US/Mountain or 
US/Mountain-NoDST (or as in your example that it wants 
America/Los_Angeles)??  Is it psychic?  I have yet to see a tool that can 
do this unless its coded with prior knowledge.  Still, once coded the 
knowledge can become stale or incorrect (ie: say AZ relents and decides to 
go along w/the US/Mountain settings).  At this point in time, our 
knowledge based technology still cannot match the CU's ability to say 
which one to use (or which they _want_ used!).

My point is simply this, a CUA should not always select the TZ settings by 
itself and we have not yet codified the way that all 'interoperating' 
implementations should work.  I dont have the magic bullet for fixing this 
apart from codifying the proper behavour for CUAs do follow when dealing 
with TZ/DST selections.  Leaving the methodology open will be just like 
the multipart/* interop test mishaps we saw at CalConnect 1.

Since the CAP folks are so gung ho on adding this ability, why not take 
the time to learn from iCals multipart/* example and clearly specify how 
_all_ CAP CUAs should function when doing this pretty key bit of 
setup!?!?!  (Just saying "the CUA will select the correct VTIMEZONE" is 
smoke and mirrors, not a real solution!)

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: [email-masked]
Date: Thu, 31 Aug 2000 15:23:41 -0400

John:
I think your scenario is different than the one that Doug Royer was 
quoting.
-- Frank

---

From: [email-masked]
Date: Thu, 31 Aug 2000 15:36:00 -0400

John replied:
>"The right one" is the one the user picks.  It has to be that
>way.[Snip]Are you going to build
>a CUA that understands the user's politics?

Now you are on my side of this chat w/Doug.  He claims he can "write a 
tool" to pick it.  I claim its not going to work and that the CU MUST be 
involved in the process; the CUA CANNOT do it properly 100% of the time 
(not that CUs are perfect but thats different...)

The current text (and the arguments from Doug) just handwave on _how_  the 
proper TZ is picked when there are multiple GEO_BOUNDS that match.  I 
objected and this thread began.  I want to have some text that 
unambiguously states the process ALL conformant CUAs follow to select the 
proper TZ, thats all!  I do not want it left up to each CUA author to make 
assumptions!!  (You missed the CalConnect 1 and multipart/* messages I 
take it...)

Bruce