[Design] [Scooby] Managing Calendar/Timezone

[Bobby Rullo]

Nice summary. I think 4) is the way to go with the least hassle for now.

The only question I have is:

	Is there a distinction between "home (or default) timezone" and  
"currently selected timezone"?

I used to think we needed both, but now I am not so sure. Mimi said:

> I think I'm just getting hung up on the word default which makes me  
> think that there's some timezone setting that resets itself at the  
> beginning of every user session (e.g. the user homepage in browsers).

which is in fact what I envisioned originally. But now I think it's  
annoying for the timezone to keep resetting itself to this, it should  
just remember what you selected last. And new events are created in  
that timezone. In other words I think it makes sense to have only  
"currently selected timezone" and that selection is persistent  
between sessions.

is there a compelling reason to have both?

On Apr 19, 2006, at 5:51 PM, John Townsend wrote:

> I agree with alot of what Jeremy said. Here was the email I was  
> working on before I read his:
>
> Maybe I am wrong, but most people I know don't care about  
> timezones. They live and work within the same timezone and don't  
> travel extensively for their job. What they do care about is "What  
> time is that meeting I have on Thursday?" and the usual answer is  
> 2pm, not 14:00 PST.
>
> But, when you are a mobile warrior and you are scheduling things  
> with people, you do care about timezones. You want to make sure  
> that the events that you schedule and attend are properly specified  
> with timezones. Then you can adjust your view to display your  
> calendar in whatever timezone you are currently in. This means that  
> if you had a meeting scheduled today at 2pm PST, when you switch  
> your timezone to EST, that event should shift to 5pm EST. This  
> allows you to easily make sure that you're not committing to  
> conflicting events at the same time (or at least you aren't doing  
> it without knowing it!)
>
> So, I guess to summarize:
>
> 1. I think its important that users have a default timezone that is  
> their home timezone. When they send requests for meetings, those  
> events are encoded with times that include their timezone. This  
> easily handles the case of the user that stays home and doesn't  
> travel.
>
> 2. I think its also important to allow the mobile warrior to turn  
> on the ability to change their timezone view from their default  
> timezone to the one they are actually in. That way they won't miss  
> that 2pm PST conference call they need to make at 5pm EST.
>
> 3. I like the iCal model that Apple puts forth. You set a  
> preference that says that I want to turn on timezone support. At  
> that point, timezones start to appear and can be changed in views  
> and when creating events. Otherwise, it handles it for you.
>
> 4. Couldn't we just ask the user to tell us their timezone the  
> first time they signin to scooby? (And make it available as a user  
> preference so they can change it.)
>
> Anyway, just my two cents. I am the new guy to this conversation,  
> so I might not fully understand all of the issues involved.
>
> --> towns
>
>
>
>
> On Apr 19, 2006, at 1:05 PM, Jeremy Epstein wrote:
>
>> 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
>>>
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Design" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/design
>