I suppose either way you're going to run into accuracy problems, but that is the nature of the beast. IP wasn't ever developed to be a geographical thing, but we're trying to get geographical info from 'guessing'. I guess it boils down to one of three things;
A> Where are Wills users going to be when accessing the site? Internal or external? From a hotel room or from another office? B> Can you trust that the user will change their clocks on their machines? C> Does Wills company go with that kind of network routing? (I don't go to hotels often, so I can't state whether each building has their own external IP or if they route as you suggest) If "A", and if they're using internal IPs, you could still get a good idea of where the users are based on their internal IP, pending you're not running the same network range in multiple locations. (Network guys love a challenge sometimes. ;)) I suppose another option would be that when a user logs into whatever service Will is offering, then a field asking for the current local time would get the most real accurate time. On Fri, Aug 1, 2014 at 7:32 PM, Donald Shepherd <donald.sheph...@gmail.com> wrote: > Actually what Rob and I were pointing out was that the chances of showing > up in Taiwan when you're in Tennessee is actually quite high in a corporate > environment - he gets moved from the UK to Germany, I get moved from > Australia to Phoenix, AZ, my wife gets moved from Australia to Switzerland > and that's just a random sample. It's not uncommon at all for large > companies to route traffic through a single gateway, and as a result using > geolocation to detect timezones is very prone to problems if people want to > access a site from inside a large company, whereas using client-based logic > avoids this. > > > On 2 August 2014 09:27, Stephen Chrzanowski <pontia...@gmail.com> wrote: > > > I understand that with routing and such, you can end up outside where you > > really are (With my IP, I'm shown just outside of Toronto when I'm > actually > > two hours out), but the chances of showing up in Taiwan when you're in > > Tennessee is doubtful. The point of the matter is that you'll get real > > time data in regards to where the user might be located and from there, > > you'll get a general idea on when a good time to call is. > > > > There are also bounce VPNs which would make it look like I'm in Texas > when > > I'm in Toronto. Depending on how I route my traffic here, I can be > > anywhere in the world. > > > > > > On Fri, Aug 1, 2014 at 5:51 AM, Will Fong <w...@digitaldev.com> wrote: > > > > > Hi everyone, > > > > > > Wow, such great responses! So my background is not with this type of > > > development, so I never really thought about these types of problems > > > before. Thank you all for the help! > > > > > > -will > > > _______________________________________________ > > > sqlite-users mailing list > > > sqlite-users@sqlite.org > > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users@sqlite.org > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
