The Location page is a sample where Resalient will guess your location using your IP address as mapped against an open source IP to Geo Location database.

Why? I was playing around with structured data the other day and was thinking of the Event type and how useful it would be if a search engine were to find an Event hosted by this platform and if the platform could assist Google or Bing by letting them know what the real UTC value for the event is.

Honestly, the approach I have taken is a bit of overkill and is still only a guess. In my first test, it showed a friend as being in Toronto, which was about 1000 miles off. The dataset I am using does not have every IP, and my pattern for guessing is highly suspect. I would have thought IP addresses were slightly more like Postal Codes in so far as attempting to keep numbers clustered by physical location. In the case of my friend, when I examined the database using only the first 3 octets, there were locations all around the world that matched the first 3 octets. In my case, my IP has no matches when selecting past the first 2 octets.

To get around this issue, the code looks for either an exact match or the nearest match on first 3 octets AND the absolute difference on the fourth; if the code cannot locate using this, it will attempt again using the first 2 octets AND the absolute difference of the third. Using this approach, I could locate the metro area for both examples.

Is this approach useful? Time will tell.

In software development, the first step to solving a problem is understanding the problem or at least having a reasonable approximation. "What is the current user's time zone?"

Next, we will ask ourselves, what available data do we have and what additional data can we collect cheaply? We may also ask UX questions such as, "will the user be willing to tell us?" Even without privacy concerns, sometimes the process of having to navigate away to a profile page to set data can be more than a user wants for a simple answer.

In terms of solving the problem, it is not always necessary to find the "best" solution, since "best" may be subjective or may be contextual. It may be that in a practical scenario the data proves too unreliable such that it would have been better to "trust" the time zone set by the user rather than to infer it through having JavaScript send us time data. In many Dynamics CRM projects, this is the route chosen when the User Profile is not utilized (eg, in a Portals project where there may be no such profile setting for an external customer.)

I would love to hear in the Contact page how close this code comes to finding your location. Was it able to find your metro area?