Major failing depends on user base and usage pattern. For me, as i travel a bit, you might be correct. For most people, it does not matter at all. I also don't know of a lot of calendars who actually deal with this in an understandable manner (actually, only Apple's iCal comes to mind, the userinterface they provide for timezone events is the only one i ever understood :)).

This is not an easy feature to implement in a manner that it does not hurt usability for the default case (beside engineering costs).

But i really like to understand (i am not part of the calendar team, so bear with my naivite) why this is actually important. If i view an event, do i really care about the specific local time of the event place? Example: i have a recurring event for Percussion lessons on my calendar. CET+1 timezone, 7:30pm. If i travel to NYC, i don't really care about that fact anymore, all i want to do is shut off the alarm in the middle of a meeting :).

Because i expect my calendar to change event times based on my observation time. It does not help me abit to enter an event in NYC time and calendar does not remind me in Europe at the correct local time.

So i venture to argue that mostly you do care about the event time relative to yourself. Now, it might be interesting to see that this was in local time Y, but is that really important in this scenario?

It becomes interesting if i talk about this to a 2nd party that is in a different timezone than i am. But i am still not sure that the timezone of the original creation is really important - i might just be missing the usage case here.

As i heard your argument made before, and i always failed to follow up to get a better understanding, please be so kind to enlighten me.

Tx

Frank Mantek

On 10/4/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:


Frank Mantek wrote:
> The problem though is that the calendar converts single event entries to UTC
> time on the server, and returns them to you in the timezone of the calendar
> they are in.
>
> What you want could only be solved by having individual timezone settings
> per entry, but we don't have that on the Google Calendar.
>

Thanks for the reply. However, it seems to me that this is a *major*
failing with Google Calendar, if it doesn't have the ability to
associate Events with a time-zone. Just storing a UTC offset is not
good-enough. It does not allow identification when (as is the case)
several different world time-zones can have same offset. And it
completely falls apart when trying to work sensibly with DST (daylight
saving time). Users do not wish to be aware of DST, but it must just
"work". They don't want to see an Evnet's time appear to change just
because their point of observation has moved from Summer Time to
Standard Time!

John Walton



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Google Calendar Data API" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/google-calendar-help-dataapi
-~----------~----~----~----~------~----~------~--~---

Reply via email to