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
