One more thing, I've added Geonames to ping service to measure its
performance and got the following statistics:
Was made 47 requests (one for every 15 minutes) with average response time
750 ms.
During this period I got some bad responses:
{"status":{"message":"the hourly limit of 3000 credits for the IP address
72.14.192.68 has been exceeded. Please throttle your requests or use the
commercial service.","value":19}}
Its availability percent (percent of expected responses) was 93.75% for the
past 12 hours.
So its probably not a good option to use Geonames in a cloud for free... but
still an option.
On Thu, Aug 19, 2010 at 19:56, Fernando Padilla <f...@alum.mit.edu> wrote:
> Yeah, i guess each his own. Though the ip resolution way does seem
> "cleaner" in some ways, it does seem way more complicated in others.. and
> dependent on other services.. etc..
>
> I guess we just realized that TimeZone Detector should be easily pluggable,
> to fit people's taste and requirements... :)
>
>
> On 8/19/10 1:36 AM, Dmitry Gusev wrote:
>
>> I didn't use one, but I believe such service exists that resolves client
>> timezone by client IP.
>> Client IP -> Location -> TimeZone. And this all may be resolved in very
>> first request.
>>
>> On Thu, Aug 19, 2010 at 10:43, Fernando Padilla<f...@alum.mit.edu>
>> wrote:
>>
>> Since our apps deals with sports team schedules, timezones are important
>>> for us. That's why I kept trying to suggest timezone support, whenever
>>> you
>>> discussed locale support.
>>>
>>> But your main question is how to determine a client's timezone. There is
>>> no http-header way to get it, and a Javascript timezone detector is the
>>> only
>>> thing I could come up with. Even with Javascript timezone detection, you
>>> will not know a user's timezone on their first request, only after the
>>> timezone detector executes, calls back to the server, and a user's
>>> httpsession has been updated with their timezone.
>>>
>>> Even if after you're OK with that, Javascript only gives you access to an
>>> offset for a particular date, but not the actual timezone Id. To get the
>>> timezone Id you have to take some offset samples for a few dates, and
>>> back
>>> track those samples against the timezone database in Java.
>>>
>>> What I did, was to take a few date samples ( jan, jun, today, two weeks
>>> from today ), and generate the offsets for those dates on the
>>> client-side,
>>> then compare those values against all known timezones on the server-side.
>>> That will give you a short list of possible timezones that will all work
>>> for the user. Then I just store that against the user (httpSesstion),
>>> much
>>> as you would store the user's Locale - through putting timezoneid in url
>>> is
>>> not an option.
>>>
>>> If you're interested, what's the best way to give you the few files that
>>> would get you started? attach to a bug?
>>>
>>>
>>> - TimeZoneLookup.java
>>> - service, does the timezone database lookup, versus date offset
>>> samples
>>> - components/common/TimeZoneDetector.java
>>> - components/common/TimeZoneDetector.js
>>> - component that executes javascript to get date offset samples, and
>>> calls back to server for capturing
>>> - doesn't render if timezone has been detected already
>>> - we have our layout include timezone detector, so all pages include it
>>> - pages/common/TimeZoneDetector.java
>>> - javascript calls back independent page (not component action)
>>> - because i don't want to deal with unnecessary page activation of
>>> pages
>>> containing the Detector
>>>
>>>
>>>
>>>
>>> On 8/7/10 9:10 AM, Howard Lewis Ship wrote:
>>>
>>> This is something that's been nagging me. Although there's a bunch of
>>>> good
>>>> options for selecting a date (or date/time) as JavaScript components
>>>> bult
>>>> into Tapestry, or available elsewhere ... none of them address the issue
>>>> of
>>>> the client and the server operating in different time zones.
>>>>
>>>> At the very least, these components probably should include a time zone
>>>> drop
>>>> down list (or other means of selection).
>>>>
>>>> I haven't been able to find a sure-fire way of determing the user's time
>>>> zone from the HttpRequest.
>>>>
>>>> I'm curious what kinds of solutions the community have used to address
>>>> this
>>>> issue. It would be nice to come up with a true solution for Tapestry
>>>> 5.3.
>>>>
>>>> One option is a bit of JavaScript that reports the client's time zone
>>>> (or
>>>> just time) to the server so that the server can identify their time zone
>>>> automatically.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>
>>>
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
--
Dmitry Gusev
AnjLab Team
http://anjlab.com
