Subject: [Ietf-calsify] VTIMEZONE - replacement idea (fwd)

From: connolly at w3.org (Dan Connolly)
Date: Fri Sep 10 16:04:28 2004

On Fri, 2004-09-10 at 02:43, Libby Miller wrote:
> from the new icalendar mailing list.

Have you told them about our repository of timezone data in XML?
 http://www.w3.org/2002/12/cal/#tzd

Would you please? If not you, is anybody else watching both lists?

http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

Hmm... I think I'll just cross-post and hope for the best...

Doug Royer wrote:
> My idea is to deprecate the VTIMEZONE object in VCALENDAR objects

I must say that seems like a strange thing to do, just when the
various tools are starting to get it right. The spec for VTIMEZONE
seems like a pretty good match for the widely-deployed Olsen
timezone database. It's maybe slightly hairier than it
needs to be, in theory; I can imagine pruning the allowed
RRULE constructs a bit. But in practice, it seems to work
nicely.

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Sep 10 17:08:31 2004

>RRULE constructs a bit. But in practice, it seems to work
Part of the debate on this list was to change RRULE. This effected
recurring events across time zones.  Also included in this debate was
how to have the client do TZ math. And VTIMEZONE contains
RRULEs and can include RDATEs.

Also in the debate on this list was listing all entries in UTC.  This
would eliminate the need for VTIMEZONE in many (all?) components.
Yet the CUA still needs to do TZ math.  So this is a proposal on
how to have simple IANA registered time zones so that everyone does
the same math.

I have modeled the proposed XML format to be compatible with the zdump 
output
format from the compiled Olson database. A simple hack to zdump should
be able to produce this XML object directly.

No need to pass the same time zone definition in each component
each time any more.

-- 

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/20040910/c9a39cae/smime.bin

---

From: leo at gnowsis.com (Leo Sauermann)
Date: Tue Sep 14 09:57:09 2004

> how to have simple IANA registered time zones so that everyone does

uhhh..
many of todays calendars in VCAL have errors about timezones.
If mozilla/kde/whatever doesn't get it, we rdf developers won't get it, too.

so I would recommend to always store time in local time format with 
timezone, because any UI (cell phone, whatever) then may display it 
without any math.

regards
Leo

---

From: charles at w3.org (Charles McCathieNevile)
Date: Tue Sep 14 09:57:10 2004

>timezone, because any UI (cell phone, whatever) then may display it

You mean something like "2004-10-04T09:00 TZID=Hungary/Budapest" or something
equivalent? That's useful to have, but I don't think in real-world
applications you can get away with not being able to do the maths.

I have a cellphone and a laptop, and sync my calendars between them. I have
several problems:

Some events have a different timezone for the start and end (most often,
aeroplane flights - the data I get gives the departure and arrival times as
local to the relevant airport. This is indeed the most comfortable way I have
found to deal with it. So to work out how to block out the right times as
"you're on the plane - you can't meet anyone for lunch" I need to
convert the time zone when I am entering the data (which is a pain) or do the
maths dynamically (which is a pain, but only for the tool developer...)

recurrent events have their time specified in different time zones. For
instance I have one recurrent meeting with times expressed in France/Paris
time, and another expressed in US/Boston time. Since these recur, it isn't
such a pain to change the time zone when I put them in, so I enter each of
them having set the machine to the relevant time zone. But in synching and in
shifting time zone bases for my tools they need to do the calculations making
sure that they don't blindly convert Boston time to Paris time (for a week or
two most years the difference is an hour more or less than it is the other
50-odd weeks) and let me miss a meeting.

One-off Web events and the like are often specified in a local time based on
where the guy writing the page is. This seems reasonable. But if I have
to shift my software around to that timezone to enter the time, it's a pain,
and any given person is unlikely to specify things in lots of timezones.

I tried keeping one clock synched to UTC and doing everything based on that.
As someone who changes timezones on average more than once a week I thought
it would make sense, but it doesn't. The maths is a bit more complex than
straight addition/subtraction, but not very. Most of the complexity is to do
with looking up tables. That sounds to me like the kind of maths that we
should rely on computers to do, since they are less likely to miss planes if
we think carefully three times and measure twice before we cut the code
(sorry to mix a carpenters metaphor) than if I have to continually do this...

cheers

Chaals

---

From: elias at cse.ucsc.edu (Elias Sinderson)
Date: Tue Sep 14 12:44:26 2004

Leo Sauermann wrote:

>> Also in the debate on this list was listing all entries in UTC [...]
>
> [...] I would recommend to always store time in local time format with 
> timezone

local to the client or local to the server? Assuming that you mean local 
to the client, this simply begs the question as to how one deals with:
* multiple clients in different timezones modifying the same calendar?
* a client, such as a cell phone, which moves between timezones?
Examples use cases provided upon request, there are many - I assume the 
reader can provide their own...

> because any UI (cell phone, whatever) then may display it without any 
> math.

The math consists of a single lookup and a single addition or 
subtraction, or the equivalent of a switch statement based on the 
current client timezone... Even cell phones can do that without 
difficulty, as can handhelds, etc.

Quite honestly, storing all times in UTC is the simplest solution. It is 
well within the extent of client capabilities to translate times from 
UTC to the local client setting. Further, this prevents servers from 
having to convert timezones for various clients in different timezones, 
makes the protocol easier to understand and, lastly, avoids unnecessary 
bloat on the wire.

Regards,
Elias

---

From: helge.hess at opengroupware.org (Helge Hess)
Date: Tue Sep 14 12:59:08 2004

> difficulty, as can handhelds, etc.

The calculation itself isn't too difficult. But storing (and updating) 
the timezone information for all the years might be a storage problem 
for cell phones? (though cell phones nowadays have enough RAM, but your 
new cell phone watch might not ;-).

> Quite honestly, storing all times in UTC is the simplest solution. It 
> is well within the extent of client capabilities to translate times 
> from UTC to the local client setting.

Except that it doesn't work for (calculated) cyclic appointments which 
need to take into account daylight savings which in turn requires the 
timezone information.
Do I miss something? (I have the impression, because this was suggested 
several times now).

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

---

From: elias at cse.ucsc.edu (Elias Sinderson)
Date: Tue Sep 14 13:00:09 2004

Charles McCathieNevile wrote:

>>[...] I would recommend to always store time in local time format with timezone, because any UI (cell phone, whatever) then may display it without any math.
>>    
>>
>[...] I don't think in real-world applications you can get away with not being able to do the maths.
>  
>
+1

>local to the relevant airport.
>
Would it be acceptable for the client to display all the times in local 
time, whatever that may be? For example, in New York you would see the 
times for the flight displayed in New York time, and when  in Paris you 
would see the times as local to Paris. Personally I could live with 
this, especially if my client allowed me to dynamically switch the 
display timezone.

>[...] recurrent events have their time specified in different time zones. For
>time, and another expressed in US/Boston time.
>
It would seem that keeping all of these times in UTC would avoid you 
having to switch the timezone settings on your client.

>[...] One-off Web events and the like are often specified in a local time based on
If we agree that the canonical server representation MUST be in UTC, I 
propose adding the following text to the spec as well. "Clients SHOULD 
allow a user to specify times for events in any timezone." At any rate, 
changing the timezone setting on your client in order to enter an event 
seems warped. (No offense intended, clearly the calendar client you are 
using is forcing you to work around it's shortcomings.)

>it would make sense, but it doesn't.
>
I've lived in multiple timezones simultaneously as well, keeping watches 
sync'd to different timezones. The real problems occurred when I was so 
tired that I put them on the wrong wrist...

>The maths is a bit more complex than straight addition/subtraction, but not very. Most of the complexity is to do with looking up tables. That sounds to me like the kind of maths that we
>should rely on computers to do [...]
>
+1

Regards,
Elias

---

From: daboo at isamet.com (Cyrus Daboo)
Date: Tue Sep 14 14:54:26 2004

Hi Elias,

--On Tuesday, September 14, 2004 1:00 PM -0700 Elias Sinderson 
<[email-masked]> wrote:

>> aeroplane flights - the data I get gives the departure and arrival times
>> as local to the relevant airport.
>>
> would see the times as local to Paris. Personally I could live with this,
> especially if my client allowed me to dynamically switch the display
> timezone.

Displaying them in your local 'display' timezone is fine, but what about 
editing them? If I enter a date-time with a specific timezone and then go 
back to edit that, I want to see it in the timezone I originally entered, 
not whatever my current 'display' timezone is.

If we do switch to using only UTC times I would like to suggest that we 
preserve the original timezone info using a 'TZHINT' attribute on the 
date-time property. That way clients would know what timezone to use when 
the user wants to edit. The question is whether that is really any 
different than what we have now...

-- 
Cyrus Daboo

---

From: helge.hess at opengroupware.org (Helge Hess)
Date: Tue Sep 14 15:18:04 2004

On Sep 14, 2004, at 23:57, Cyrus Daboo wrote:
> Displaying them in your local 'display' timezone is fine, but what 
> about editing them? If I enter a date-time with a specific timezone 
> and then go back to edit that, I want to see it in the timezone I 
> originally entered, not whatever my current 'display' timezone is.

-1.
I don't know in what situation that would be important. Sounds more 
like a free form history log for informational purposes (like "created 
as event 'blub' in Seattle, PST").

> If we do switch to using only UTC times I would like to suggest that 
> we preserve the original timezone info using a 'TZHINT' attribute on 
> the date-time property.

+1
Sounds good! An optional attribute which transports that information.

> That way clients would know what timezone to use when the user wants 
> to edit.

This is relevant for calculated cycles, in all other cases the user 
will probably expect the current view timezone to be used for edits as 
well (not to be discussed, opinions might differ ;-).

>  The question is whether that is really any different than what we 
> have now...

Yes it is! The storage/transport would be allowed to ignore the hint 
(which will be quite usual if you consider the amount of requests for 
UTC!), but systems supporting the hint could still provide the 
information.
Which is why I like the solution.

The "issue" to be solved are calculated cyclic appointments. I would 
personally vote to remove them, but I know that a lot of 
devices/clients already depend on it (eg Palm PDAs and Outlook). I see 
three levels of recurrence support:

a) no recurrences in the protocol (client must flatten cycles to 
individual events),
    implies that timezone info is not necessary anymore (hurray!)
b) recurrences allowed on creation, kept in storage (servers will 
return individual
    events on queries). Only needs timezone for recurrences on creation.
c) recurrences fully supported (current situation). Client and server 
need to be fully
    timezone aware and have consistent information on that.

Reducing to a) would certainly make the protocol/format a _whole_ lot 
easier. b) still gives a big boost in interoperability and is easier. 
But c) is actually required for a lot of systems.

best regards,
   Helge

---

From: charles at w3.org (Charles McCathieNevile)
Date: Wed Sep 15 05:32:13 2004

>this, especially if my client allowed me to dynamically switch the

That's what I have at the moment. If I find a calendar program that does
better, I'll ditch the current one. The problem is as follows:

I am in Antibes, and I have a flight that goes from Frankfurt (same time zone
as Antibes in this case) to Shanghai (some other time), where I meet my
mother. She wants to know when I get to the airport. I'd like to have the
time blocked off for making appointments according to Antibes time (and so I
can see how many hours I will spend in the plane, but I want to be able to
quickly look up my arrival time in the most useful form, which is generally
going to be Shanghai time. (Not always, but IMHO there should be nothing to
stop me noting an event in UTC or something if I want to).

>having to switch the timezone settings on your client.

Not really, unless you are prepared to switch each instance of a recurrent
event, checking when the changes to summer time are. In fact it is important
on some timezones to know what the original timezone was, since you can't
always predict in advance when timezones shift. (In 2000, the state of New
South Wales announced that it would introduce summer time many weeks earlier
than usual to allow for better TV programming times for the Olympics. I don't
want to have to then tell my calendar to recalculate everything that was
noted in sydney time originally by hand - if I have to tell it that Sydney is
already on summer time (I believe that I still have to do that currently)
that's more than enough hassle.

>>[...]
>If we agree that the canonical server representation MUST be in UTC,

I don't - I think the idea of keeping the thing in a local time and noting
its timezone is a good one. I just don't think that it achieves the goal of
avoiding the maths. On the other hand it achieves the goal of maintaining an
important data point so we can get the right result if we do the maths right,
in a way that seems (to me) likely to be less troubling in the long run than
always
relying on UTC.

cheers

Chaals

---

From: connolly at w3.org (Dan Connolly)
Date: Wed Sep 15 08:44:21 2004

> If mozilla/kde/whatever doesn't get it, we rdf developers won't get 

But mozilla/kde/whatever do get it, increasingly.

Don't let's fall into the trap of thinking that producing new 
specifications
will fix the fact that the old ones aren't implemented well.

> timezone, because any UI (cell phone, whatever) then may display it 

But if it can't tell that a meeting at 1pm NY time conflicts with a 
meeting at 12noon Chicago time, what good is that? Just use plain text 
if you don't want the computer to actually help.

-- 
Dan