Re: DISCUSSION: Time zones and date selection

[Dmitry Gusev]

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  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
>>  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
>
>


-- 

Re: DISCUSSION: Time zones and date selection

[Fernando Padilla]

 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  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

Re: DISCUSSION: Time zones and date selection

[Dmitry Gusev]

Here's the service description:
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  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 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 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
>>>
>>>
>>
>>
>> --
>> Dmitry Gusev
>>
>> AnjLab Team
>> http://a

Re: DISCUSSION: Time zones and date selection

[Dmitry Gusev]

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  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  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
>>
>>
>
>
> --
> Dmitry Gusev
>
> AnjLab Team
> http://anjlab.com
>



-- 
Dmitry Gusev

AnjLab Team
http://anjlab.com

Re: DISCUSSION: Time zones and date selection

[Dmitry Gusev]

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  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
>
>


-- 
Dmitry Gusev

AnjLab Team
http://anjlab.com

Re: DISCUSSION: Time zones and date selection

[Fernando Padilla]

 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

Re: DISCUSSION: Time zones and date selection

[Joost Schouten (mailing lists)]

Hi,

I do everything server side with the help of a custom
TimeZoneAwareDatePicker wrapping your tapx datepicker. It takes a
source (I store everything in UTC) and display timezone (the users
timezone) to do the conversion. This suits me because I will almost
always know my users timezone as they need to be logged in.

In all my applications where I need to be timezone aware, I make sure
to have my users specify it upfront and store it all server side. To
help my users I assume the most logical tz through some util classes I
build around http://icu-project.org/apiref/icu4j/. These util classes
have methods like getBestMatchingTimeZone(Locale locale).

Personally I wouldn't want to add a time zone drop down to a date
picker as it would be too much in my opinion.

Cheers,
Joost

On Sat, Aug 7, 2010 at 6:10 PM, 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.
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to learn
> how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: DISCUSSION: Time zones and date selection

[Christophe Cordenier]

Hi

Just an add, related issue was reported there
https://issues.apache.org/jira/browse/TAP5-841


2010/8/7 Howard Lewis Ship 

> 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.
>
> --
> Howard M. Lewis Ship
>
> Creator of Apache Tapestry
>
> The source for Tapestry training, mentoring and support. Contact me to
> learn
> how I can get you up and productive in Tapestry fast!
>
> (971) 678-5210
> http://howardlewisship.com
>



-- 
Regards,
Christophe Cordenier.

Committer on Apache Tapestry 5
Co-creator of wooki @wookicentral.com

DISCUSSION: Time zones and date selection

[Howard Lewis Ship]

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.

-- 
Howard M. Lewis Ship

Creator of Apache Tapestry

The source for Tapestry training, mentoring and support. Contact me to learn
how I can get you up and productive in Tapestry fast!

(971) 678-5210
http://howardlewisship.com