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

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.

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

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

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

Received on Tuesday, 14 September 2004 20:11:48 UTC