[Design] [Scooby] Managing Calendar/Timezone

[Jeremy Epstein]

Just to chime in, one thing you might want to take into account is 
"when" a user would actually care. Personally, If I were making 
appointments  (even if I knew I were traveling) I would not concern t 
myself with timezone. -- I would always expect my calendar to be in my 
"home" time zone, or even better, not care about timezone unless it may 
cause a conflict such as the two circumstances below:

*For me, there are only two circumstances where the timezone I am in 
matters: *
    1) if an appointment I am making might conflict with travel across 
timezones (such as an international flight) This is a very strange case. 
It means I have an event (airplane flight) that starts in one timezone, 
and ends in another!
    2) if I am planning a conference call across timezones, i.e. if I 
have a phone meeting with a matthew and bobby.  In the conference call 
case, I would expect the event to list all the times for all the parties 
involved: (12:00 noon my calendar time, 2:00pm  matthews time)
    

Another example of why I would not want any calendar changing time zones 
without my explicit control:

I am traveling to a conference in Chicago, and I make an appointment to 
meet a  colleague for lunch  (12:00), even though (12:00) in Pacific 
Standard Time(my "home" time zone) would nominally translate to 2:00 pm 
Chicago time. However, I KNOW I am going to Chicago, and if I set an 
appointment for 12:00 noon, I would assume its for 12:00 noon whether I 
am in Chicago or San Francisco. Since chandler has no notion of 
geographic travel, I don't want it switching time zones on me. Also, I 
don't want to do the mental math required to set a lunch date of 2:00:pm 
Pacific Standard Time (my "home" time zone) just to make sure the lunch 
date appears at noon when I arrive in Chicago and my calendar resets its 
timezone or I connect from an Internet cafe with a computer whose clock 
is set to Central Standard Time. Does this make sense?

One last thing, it may simply suffice when traveling to show two clocks 
on somewhere on the calendar display:  Calendar time, and current 
geographic time.


Apologies for the long note.

Jeremy Epstein



Bobby Rullo wrote:
>
> On Apr 19, 2006, at 12:08 PM, Steve Lewis wrote:
>
>> Bobby Rullo wrote:
>>> Also possibly a 3rd:
>>> 3. System "guesses" initial timezone based on IP address to location 
>>> table for initial log in
>>
>> [delurk]
>>
>> A fourth possibility would be to detect their timezone every time they
>> log in.  If the current client's detected timezone is different, ask the
>> user if he/she would like to adjust the user's timezone, and the
>> calendar view, to use the detected time zone or continue to use the
>> stored timezone.
>>
>
> Interesting idea. We'd have to make it annoying proof so that the dude 
> who always wants their timezone to be EST even though they are in CA 
> doesn't get harassed.
>
>> You can determine the timezone without the IP address to location table
>> which has a significant margin of error.
>>
>> As a hint toward implementation, adapt or adopt this javascript library:
>>
>> http://west.ilrn.com/media/js/systemCheck/timezone.js
>
> That only works if the system's time has changed.  Like someone went 
> to the System Preferences panel and clicked "change timezone" Might 
> not always be the case for laptop users who are bouncing around a lot.
>
>> and then search java.util.TimeZone for a timezone that has the same
>> summer and winter DST offsets, then filter that down further by
>> timezones that switch DST at the amount.  This will often give several
>> possible but equivalent matches.  Programmatically solve this by always
>> choosing one, e.g. the first.
>>
>
> The problem I see with this approach is that it would have to favor 
> some locale's over others - New York and Buenos Aires might have the 
> same offset, but which one would appear first in the list? Americans 
> would be annoyed if Buenos Aires always appeared first because it 
> begins with B and Argentineans would be annoyed if New York appeared 
> first just because it's American...
>
> Is the margin of error for IP address tables really that bad? We don't 
> have to get within a block, just within the general region.  I thought 
> they were ok for that, but don't really have any data to support it 
> either way.
>
>
> Bobby
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design
>