Subject: [Ietf-calsify] Time Zones

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Wed Aug 18 05:41:21 2004

I think time zones are more easily mapped to time deltas than GEOs...
for probalby every client and system.  But I've heard other requests to
standardize and simplify the timezone story.  Here's a radical idea -
what if we only used the military time zone references? These are fairly
standard (within one community, anyway).  We have adopted Zulu pretty
readily, how about we just go with the rest of the alphabetic standard?
For those interested, here it is:

A : UTC+1
B : UTC+2
C : UTC+3
D : UTC+4
E : UTC+5
F : UTC+6
G : UTC+7
H : UTC+8
I : UTC+9
K : UTC+10
L : UTC+11
M : UTC+12
N : UTC-1
O : UTC-2
P : UTC-3
Q : UTC-4
R : UTC-5
S : UTC-6
T : UTC-7
U : UTC-8
V : UTC-9
W : UTC-10
X : UTC-11
Y : UTC-12
Z : UTC

(for those curious about why Juliet was left out...? It's not about the
tragic Capulet, but the tragic army officer named Custer, and the army's
inability to forgive him...)

Alternatively - what if there are only floating times and zulu times?
All other time zone processing could be pushed to the client - is that
too draconian? 

Also... concerning GetCapabilities - that doesn't necessarily work for a
standalone .ics file that I publish to a website... But I completely
agree with your assessment of RRULE as a means of communicating a vast
recurrence set tersely.  This is why I think we should not completely do
away with it, but rather simplify it.

Regards,
cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, August 17, 2004 8:37 PM
To: [email-masked]
Subject: [Ietf-calsify] Thoughts on some of the simplification thoughts
sofar

If you start breaking out VTODOs, VJOURNALs, or whatever, then perhaps
you're on a path where you have a multi-layered standard:

         Layer 0 would be representation of the "generic" parts of the
object (DTSTAMP, UID, DTSTART(?) etc.)
         Layer 1 would be representation of specific items, perhaps one
standard per VEVENT/VTODO/VJOURNAL, etc.

Endpoints of a calendaring conversation would have to either identify
what objects they could deal with, or issue errors when passed an object
they couldn't, or both.

Elimination of recurrence rules by passing lists of date/time values
back and forth overlooks the advantage of using the "shorthand" of
recurrence rules, which allow a large list of dates and times with a
short rule. I'm not arguing for or against, just making a point that I
hadn't heard expressed.  If you end wanting both possibilities, you have
to have a discovery mechanism to see what the other end handles. This, I
think, is at least partly handled by the "expand recurrence" property
which is returned in the GET-CAPABILITY response (I think).

Elimination of GEO values - I would rather see GEO be used as an index
into timezone data, rather than passing the timezone data along with the
objects, since a geographic location rather efficiently can get you the
timezone information. If eliminated, then I would like to see another
document for standardization of time zone identifiers, and only pass the
identifiers, not all of the time zone rules themselves.

Tim Hare
Interested Bystander, Non-Inc. 

_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: helge.hess at opengroupware.org (Helge Hess)
Date: Wed Aug 18 05:52:37 2004

> All other time zone processing could be pushed to the client - is that

IMHO this is the correct approach. Timezones are a "view layer" thing 
and need to be processed by the client. Allowing arbitary timezones in 
the transport or storage just produces duplicate code and the 
possibility of mismatches.

The one place where timezones might be required are recurring events, 
though I can hardly imagine that this is properly implement by any 
client out there ;-)

best regards,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

---

From: danw at novell.com (Dan Winship)
Date: Wed Aug 18 07:48:29 2004

> The one place where timezones might be required are recurring events,

Exactly so. We can't drop time zones unless we're dropping unbounded
recurrences as well. (Which I don't think we should.)

> though I can hardly imagine that this is properly implement by any 

There seems to be a lot of failure of imagination going on on this
list. :) There are certainly clients that implement this properly.

And I think we need to keep it in the spec. Weekly conference calls with
people in other countries that have different daylight savings time
rules than you are a fact of business life these days.

-- Dan

---

From: helge.hess at opengroupware.org (Helge Hess)
Date: Wed Aug 18 08:00:44 2004

> recurrences as well. (Which I don't think we should.)

OK.

What do you think about attaching the timezone rule directly to the 
cyclic event? The dates of the event could still be required to be 
specified in UTC and the rule would just need to specify the ranges 
where this the cycle is different?
This might be easier to handle by both, clients and servers?

Greets,
   Helge

---

From: graham.gilmore at oracle.com (Graham Gilmore)
Date: Wed Aug 18 09:22:22 2004

There are some time zones whose offsets don't fall on the hour, and 
would be unrepresentable with this proposal.

	Graham

---

From: Doug at Royer.com (Doug Royer)
Date: Wed Aug 18 09:52:06 2004

>For those interested, here it is:
...

Sounds like a good idea. The probem is that some time zones are not
multiple of 60 minutes. Some are 30 minutes, and a few are 15 minutes.

So we added UTC-OFFST.

Second problem is that the rule for when to change the time are not
uniform and are subject to local cival authority. For example when I was
young some parts of  area did not go to daylight savings time, others did.
So its not a UTC offset problem. its a mapping the UTC offset problem
into what each users wall clock says is the time.

So we added the VTIMEZONE, and allowed objects to point
to the VTIMEZONE objects. I am not against simplification. I am
against not being able to tell what time I need to pick up the
phone and get on a conferenec call to some country where my
one year old application can not resolve its time to wall clock time.

This problem is even more complecated by simple recurring meetings.

Again I would love simplification. But its not that simple of a problem.

A manager wants to say 'have everyone be on the conference call
at 10am my wall clock time each Monday". Regardless of the UTC
offset this monday here vs the UTC offset on monay 3 months from now
after daylight savings time changes in his time zone and not yours.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)520-4044
http://Royer.com/People/Doug   | Fax:    (866)594-8574
                               | Cell:   (208)520-4044

              We Do Standards - You Need Standards

-------------- 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/20040818/ee63775e/smime-0001.bin

---

From: lisa at osafoundation.org (Lisa Dusseault)
Date: Wed Aug 18 10:04:11 2004

> rules than you are a fact of business life these days.
Recall that in order to take iCalendar to Draft Standard, the 
specification MUST drop any features that aren't implemented and 
interoperable -- CalConnect is part of the effort to document tested 
interoperable features.  So the consideration "need to keep it in the 
spec" must be followed by, not theoretical use cases, but actual tested 
interoperability (either already documented, or performed between now 
and submitting to draft standard).

Lisa

---

From: Robert_Ransdell at notesdev.ibm.com ([email-masked])
Date: Wed Aug 18 10:18:14 2004

The timezone component has been tested in several interops

Lisa Dusseault <[email-masked]> 
Sent by: [email-masked]
08/18/2004 01:03 PM

To
Dan Winship <[email-masked]>
cc
[email-masked]
Subject
Re: [Ietf-calsify] Time Zones

Lisa

---

From: Robert_Ransdell at notesdev.ibm.com ([email-masked])
Date: Wed Aug 18 11:16:29 2004

The driving issue for timezones was for repeating meetings that cross 
daylight/standard date.  The date that daylight/standard switch occurs on, 
depends on the timezone of chair not the timezone of invitee.  Because of 
this just sending offsets causes problems.

Doug Royer <[email-masked]> 
Sent by: [email-masked]
08/18/2004 12:51 PM
Please respond to
[email-masked]

To

Subject

...

So we added UTC-OFFST.

--

---

From: anil.srivastava at Sun.COM (Anil SRIVASTAVA)
Date: Wed Aug 18 12:31:28 2004

There are timezone on the 1/2 hour [India] and 45 minute [Kathmandu] 
boundaries that are not represented by the table below.  

Anil

On 2004-08-18/05:41 [-0700], [email-masked] [Cameron...:

> for probalby every client and system.  But I've heard other requests 
> to standardize and simplify the timezone story.  Here's a radical idea 
> - what if we only used the military time zone references? These are 
> fairly standard (within one community, anyway).  We have adopted Zulu 
> pretty readily, how about we just go with the rest of the alphabetic 
> standard? For those interested, here it is:
> 
> A : UTC+1
> B : UTC+2
> C : UTC+3
> D : UTC+4
> E : UTC+5
> F : UTC+6
> G : UTC+7
> H : UTC+8
> I : UTC+9
> K : UTC+10
> L : UTC+11
> M : UTC+12
> N : UTC-1
> O : UTC-2
> P : UTC-3
> Q : UTC-4
> R : UTC-5
> S : UTC-6
> T : UTC-7
> U : UTC-8
> V : UTC-9
> W : UTC-10
> X : UTC-11
> Y : UTC-12
> Z : UTC
> 

-- 
__________
Anil SRIVASTAVA
[email-masked]

---

From: TimHare at comcast.net ([email-masked])
Date: Wed Aug 18 17:40:35 2004

Cameron - can you provide a link to information about this time zone 
scheme? Is it based entirely upon 15 degrees of longitude or does it "zig 
zag" like time zones do? What about places like Indiana and Arizona that 
don't participate in daylight savings time? I am interested in reading more.

  I have previously have-jokingly suggested a WG to discuss a new solution 
for time instead of timezones :-), this might be close.  Timezones were 
invented, if I'm not mistaken, sometime after the advent of railroad 
transportation, it might be time (pun intended) to look again at Timezones 
themselves.

All kidding aside, though, my idea was to map FROM a GEO, TO a timezone - 
if you know where you are, you definitely can know what timezone you're in 
by some sort of table/database lookup without it being encoded in the 
calendar items transported.  What the military uses probably meets that 
criteria(?) and this does look like a simple proposal.

Tim Hare

Tim Hare

---

From: TimHare at comcast.net ([email-masked])
Date: Wed Aug 18 17:58:15 2004

The additions (UTC OFFSET and VTIMEZONE) mentioned seem to me to make a 
pretty good case for all times being stored or exchanged to be in Zulu 
time, and leave the local time as a OS/UI problem. On the mainframe I work 
on, things are handled this way - the hardware clock is set to Zulu time, 
the timezone offset is stored as a parameter to the OS, and the calls 
applications make to the OS get time can return either value depending upon 
the need (database logging uses Zulu, displaying today's date on a screen 
uses local time, for example).

This would push some of the time complexity out of the iCalendar protocol 
and implementations, to the OS. But that's not necessarily bad, the OS 
should be the one source for time info for anything executing on that piece 
of hardware, in my opinion.

One other use case that hit me last summer, when I was trying to create a 
file for my PDA, and which has to be accounted for: when the client will be 
physicially moved to a new time zone. Specifically, I wanted to add 
conference session events, but I did NOT want to change my PDA's time to 
the local time when I got there. I solved it then by using floating time 
for all events, but storing everything in floating time causes  problems 
when you are synchronizing people across multiple timezones.

Tim Hare

Tim Hare

---

From: lisa at osafoundation.org (Lisa Dusseault)
Date: Wed Aug 18 18:11:41 2004

The GEOPRIV WG might have some technology that would help us in that 
plan.

lisa

On Aug 18, 2004, at 5:33 PM, [email-masked] wrote:

> scheme? Is it based entirely upon 15 degrees of longitude or does it 
> "zig zag" like time zones do? What about places like Indiana and 
> Arizona that don't participate in daylight savings time? I am 
> interested in reading more.
>
>  I have previously have-jokingly suggested a WG to discuss a new 
> solution for time instead of timezones :-), this might be close.  
> Timezones were invented, if I'm not mistaken, sometime after the 
> advent of railroad transportation, it might be time (pun intended) to 
> look again at Timezones themselves.
>
> All kidding aside, though, my idea was to map FROM a GEO, TO a 
> timezone - if you know where you are, you definitely can know what 
> timezone you're in by some sort of table/database lookup without it 
> being encoded in the calendar items transported.  What the military 
> uses probably meets that criteria(?) and this does look like a simple 
> proposal.
>
> Tim Hare
>> to

---

From: elias at cse.ucsc.edu (Elias Sinderson)
Date: Thu Aug 19 10:50:55 2004

>boundaries that are not represented by the table below.  
To say nothing of Darwin, Australia (GMT+930), which I believe was 
mentioned in a previous post...  :-)

Personally, I'd really prefer to see all times represented over the wire 
and on the server in UTC, with the client being ultimately responsible 
for time conversions to/from local time, including dealing with daylight 
savings. This approach greatly simplifies or outright eliminates many of 
the issues that have been brought up, such as Dougs use case in which a 
manager wants to schedule a recurring conference call at 10am each 
monday in his time zone. In this case, the meeting is scheduled at a 
fixed UTC time and any clients would convert the scheduled UTC time into 
the local time on any given day.

WRT bringing this spec to draft status, I believe the above approach 
will offer the path of least resistance towards demonstrating the 
necessary interoperability.

Regards,
Elias

---

From: nsb at guppylake.com (Nathaniel Borenstein)
Date: Sat Aug 21 16:10:51 2004

> this just sending offsets causes problems.

Note that if we took the approach I describe in my "Mandatory Sets, 
Optional Rules" message, you could do the time zone "correction" on the 
sender end, where you presumably had the right time zone information, 
and you could describe it in a "rule description language" that made 
use of time zones, thus making time zones an entirely optional feature 
for the simplest implementations.