Here's the service description: http://www.geonames.org/export/web-services.html#timezone
<http://www.geonames.org/export/web-services.html#timezone>And JSON example for ping-service (XML is service also there): http://ws.geonames.org/timezoneJSON?lat=37.41&lng=-122.05 {"time":"2010-08-19 01:56","countryName":"United States","sunset":"2010-08-19 19:55","rawOffset":-8,"dstOffset":-7,"countryCode":"US","gmtOffset":-8,"lng":-122.05,"sunrise":"2010-08-19 06:27","timezoneId":"America/Los_Angeles","lat":37.41} On Thu, Aug 19, 2010 at 12:49, Dmitry Gusev <[email protected]> wrote: > In addition to my previous message: > > > http://stackoverflow.com/questions/41504/timezone-lookup-from-latitude-longitude > > I will probably use this approach to determine initial client timezone > since I'm already use URL/IP to location functionality there: > > http://github.com/dmitrygusev/ping-service/blob/master/ping-service/src/dmitrygusev/ping/services/IPUtils.java > > (FYI this class uses http://ip-whois.net to resolve locations.) > > In current implementation I'm using UTC time by default in ping-service > (GAE's default timezone), but user may specify its timezone in profile. > > On Thu, Aug 19, 2010 at 12:36, Dmitry Gusev <[email protected]>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 <[email protected]>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: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >> >> -- >> Dmitry Gusev >> >> AnjLab Team >> http://anjlab.com >> > > > > -- > Dmitry Gusev > > AnjLab Team > http://anjlab.com > -- Dmitry Gusev AnjLab Team http://anjlab.com
