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

On Tue, 14 Sep 2004, Elias Sinderson wrote:

>Charles McCathieNevile wrote:
>
>>On Tue, 14 Sep 2004, Leo Sauermann 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
>
>>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.
>>
>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.

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

>>[...] 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.
>>
>It would seem that keeping all of these times in UTC would avoid you
>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

Received on Wednesday, 15 September 2004 12:32:07 UTC