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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
