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

On Tue, 14 Sep 2004, Leo Sauermann wrote:

>> 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.
>
>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.

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

Received on Tuesday, 14 September 2004 15:40:33 UTC