[Design] [Scooby] Managing Calendar/Timezone

[Bobby Rullo]

On Apr 19, 2006, at 1:02 PM, Steve Lewis wrote:

> Bobby Rullo wrote:
>
>> 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.
>
> Yes.  I'll wave my hands dismissively and say that can be solved,  
> however. :)
>

Me too :-)

>>> 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.
>
> True.  It doesn't work perfectly for the laptop, but it does work  
> fabulously for the Internet cafe.  That was what I designed this  
> solution to address.  Your requirements may vary.
>

Yup.

>> 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...
>
> Location bias is a good issue to consider.  I believe that it can  
> likely be resolved programmatically.  It may require brainstorming  
> for solutions.
>
> For my purposes, I keep the idea of positional descriptors and time  
> zone separates, and don't actually display a positional descriptor,  
> for my solution.  I have special needs, however.
>

I don't see how you can can keep positional descriptors and timezones  
separate - timezones are not merely offsets, they have rules as to  
when to change those offsets. Timezone A and Timezone B might have  
the same GMT offset today, but they might be an hour off from each  
other tomorrow.

>
> Coincidentally, I have been working in this area recently.  Through  
> most of the vendors of IP address to GIS location mapping data,  
> they freely admit that in North America, 2-8% of their records are  
> absolute garbage.
>

Interesting

> Note that I did say vendors:  this information is not cheap to  
> collect and maintain and you might find it challenging to get  
> access to a world-wide mapping DB that will align with your  
> licensing plans. Maintenance of the data is a significant issue.   
> Stats are available on the rate of change in this data from some of  
> the vendors, but I don't recall them.
>

Yeah, that is a tricky part. I just had it filed away under "areas  
needing more research". It might be the case that there is no such  
product that would fit our licensing needs.

> I did find one open project to build and maintain a related  
> database. It was GB in size which could be prohibitive for users  
> wishing to deploy Cosmo & Scooby.  You would have to review  
> licensing if you wanted to plan for users to use this project's  
> webservice.  It would likely require a fee for use in those cases.
>

Could you provide a link to that project please?

> Beyond that, you can get close enough for time zone determination  
> purposes (+/- 5 miles for 80%+ and +/- approx 25 miles for 92-98%  
> of users in North America).  Outside the US, the margin of error  
> can get as high as 15% or more.  Anecdotally, I can point out an  
> individual IP that registers with everyone as being in NZ but is in  
> fact based in Seattle.
>
> That may change, and my research may have missed something, but  
> this reflects the status what I found from my research (Oct-Nov 2005).
>

Thanks for that info. That's certainly something to take into account!

Thanks Steve,

Bobby