Subject: Re: VTIMEZONE conflicts - possible solution

From: [email-masked]
Date: Tue, 8 May 2001 10:30:35 -0400

Damon wrote on 05/07/2001 04:29:35 PM:
> > That's what TZNAME is for.
> 
> Yeah, maybe. But why isn't TZNAME a property of the VTIMEZONE component?
> It seems silly to duplicate it within each STANDARD and DAYLIGHT 
subcomponent.

Because humans dont just call it "Eastern" (not "New York"); we refer to 
"Eastern Standard Time" or "Eastern Daylight Time".  Sometimes folks do 
not make a disctinction (ie: my mother who it TZ shift illiterate) and she 
just says "Eastern" but for scheduling purposes the disctinction is 
necessary.  For places that do not observe Daylight Savings (ie: Arizona 
or Idaho in the US) we do not distinguish between "MST" or "MDT", its just 
"Mountain".  For places like that you could argue that its logical to have 
a TZNAME on the VTIMEZONE but a VTIMEZONE is not really something that a 
CU is going to ever see.  It is a container for TZ shift info and its 
subcomponents are really the ones that affect what name is shown to the CU 
when resolving across TZ shifts.

Besides, I dont like model changes like this for the minority cases; too 
disruptive for the potential gain.

> And if the TZNAMEs are actually different in some of the STANDARD and 
DAYLIGHT
> components, which one do we display?

You display the TZNAME that is used for a particular instance.  So, for 
our 'weekly Monday 10AM conference calls starting in March and ending in 
May' your CUA would roll that out into some "EST" and some "EDT" values. 
They would both be 10AM but some would be labled "10:00 AM EST" and some 
BETTER be labeled "10:00 AM EDT" if I chose to see the TZ name. 

If you code your CUA to always resolve to the local TZ no matter the 
originating/reference TZ then you will probably have some form of UI 
setting that says "Show me TZ names" or possibly even "Show me in this and 
another TZ" (ie: I want to see it in my local TZ plus in Steve's local TZ 
so I can tell what time it is for him as a courtesy, etc).  (See Lotus 
Organizer for this kind of feature in action)  Here again is where you 
would want to have the right TZ tags.

Sounds like you preferr to have an "Eastern" for all America/New_York 
entires instead of an "EST"/"EDT" distinction and would like it moved to 
the VTIMEZONE...  Even so, the TZNAME is a 'friendly' name and cannot 
fully replace TZID (at least in the proposals on the table now).  TZID is 
used for internal indexing for TZ shift finding.  TZNAME is intended to be 
used in the actual UI.  As such, nothing is really really gained.

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: Alan Davies <[email-masked]>
Date: Tue, 08 May 2001 10:48:51 -0400

In many User Interfaces, your mother's view is more
sensible. When selecting a TimeZone I wouldn't expect a CUA
to present me with the choice of "Eastern Standard Time",
"Eastern Daylight Time", "Pacific Standard Time", etc... I
would instead expect to choose between "Eastern Time" and
"Pacific Time", and have the software make the appropriate
Daylight/Standard adjustments.

Perhaps there should be a TZNAME (or equivalent) in the
VTIMEZONE as well as within the STANDARD and DAYLIGHT
subcomponents.

--Alan

At 10:30 AM 08/05/2001 -0400, [email-masked] wrote:

>May' your CUA would roll that out into some "EST" and some "EDT" 
>values.  They would both be 10AM but some would be labled "10:00 AM EST" 
>and some BETTER be labeled "10:00 AM EDT" if I chose to see the TZ name.
>

---

From: "Shannon J. Clark" <[email-masked]>
Date: Tue, 8 May 2001 10:54:08 -0500

To continue with this example - most of the time people (end users that is)
think in terms of where they live (or where they are going) to get to the
timezone to use.

So - if I am putting an event into my calendar for while I am in Paris - I
want my application to present me with an option for "Paris, France" time -
which will be adjusted correctly for Daylight savings time - and does not
require me to know the name for Europe's timezone. If I am going to a
non-major city, I'm comfortable looking for a city that I know is close by
and which I assume is in the same timezone (i.e. if I am going to the Loire
Valley in France - Paris time will work fine for me.)

Others on this list have pointed out that users in Canada think of their
timezones - even the ones that overlap with US timezones in terms of
Canadian cities - not US cities.

It does seem sensible to me that there should be mechanism for multiple
TZNAME's to map to the same set of timezone rules - i.e. to map to the same
TZID potentially.

Shannon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Alan Davies
Sent: Tuesday, May 08, 2001 9:49 AM
To: [email-masked]
Subject: Re: VTIMEZONE conflicts - possible solution

--Alan

---

From: Eric Busboom <[email-masked]>
Date: Wed, 9 May 2001 16:46:01 -0700 (PDT)

> TZNAME's to map to the same set of timezone rules - i.e. to map to the same

I think that the ideas behind this thread are generally sensible -- that
humans need to understand timezone names as relating to a particular place
or region -- but I think solution is outside of iCalendar.

There are two problems to consider:

  (1) Given a common name of a region, how does a user select the timezone
  rules to apply to a meeting request?

  ((2) Given an incoming request, how does the user know what timezone
  rules apply?

The answer to (1) is that the CUA creates its own list of Olsen
place names, city names, or timezone region names and maps them into TZIDs
in its own timezone database. The user picks a common name or place, and
the CUA figures out what TZID to use. No need for a special solution here.

For (2), the receiving user has LOCATION and TZNAME ( & sometimes GEO) in
the incoming event request.  If you get a message that has:

	Bob's Jazz Cafe, Manhattan
	July 10, 2001, 14:00 EST

The "Manhattan" and  "EST" are all you need to understand where the
meeting is and what timezone applies. Even if the sender did not include
"Manhattan", you are very unlikely to get an event request for a far-flung
timezone without some out-of-band arrangements for the trip. You are not
going to be looking through the Seattle street maps at 13:00 on the day of
this meeting.

TZNAME is defined at "customary designation for a time zone description"
so timzone-database builders could pick whatever people best understand.
They could call it "Eastern Standard Time" if they want. It is not our
concern if the user does not understand the "customary designations" --
that is a problem for the user and the and the builders of the timezone
databases.

I don't think we should add any special structure to TZID, and I certainly
don't think we should try to format it so parts of it can be displayed to
the user. These are solutions for problems that are not in our realm.

eric.

---

From: John Stracke <[email-masked]>
Date: Fri, 11 May 2001 16:23:38 -0400

[email-masked] wrote:

> > It seems silly to duplicate it within each STANDARD and
> DAYLIGHT subcomponent.
>
> Because humans dont just call it "Eastern" (not "New York"); we
> refer to "Eastern Standard Time" or "Eastern Daylight Time".

Not necessarily.  Suppose you've got something that happens every
day at 8:00 all year; you have to refer to "Eastern Time",
because "8:00 Eastern Standard Time" is a fixed GMT offset.

> Sometimes folks do not make a disctinction (ie: my mother who
> it TZ shift illiterate)

Or, for example, TV stations, which say things like "8/7 Central
and Mountain" (when the transmitter is near the Central/Mountain
border).  This is common enough

> > And if the TZNAMEs are actually different in some of the
> STANDARD and DAYLIGHT
> You display the TZNAME that is used for a particular instance.

And which one do you put in the menu for the user to choose from
when they haven't chosen a date yet?

I think Damon's right; we should be able to put a TZNAME in the
VTIMEZONE.  There would still be TZNAMEs in the STANDARD/DAYLIGHT
components.

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |Stupid, adj.: Losing $25 on the game and $50 on|
[email-masked]|the instant replay.                            |
\================================================================/