My final solution was to patch DateField.java and datefield.js so that
neither use 'getTime'. Instead I translate into "yyyy-MM-dd" format for
transportation, and read/write that on the server with the same tz as
the DateFormat supplied by the format parameter.
If some of your users are in a different timezone to your server, be
very careful with this component. it is currently broken.
https://issues.apache.org/jira/browse/TAP5-1575
On 12/07/2011 10:25 AM, Paul Stanton wrote:
From looking at the code, it seems like DateField will always have
issues if the DateFormat parameter does not have the same TimeZone as
the client's browser.
The reason being,
this server side java code in the context of the DateField component:
return format.parse("01/07/2011").getTime()
needs to return exactly the same value as the following JS executed on
the client:
var d = new Date();
d.setDate(1);
d.setMonth(7);
d.setFullYear(2011);
d.setHours(0);
d.setMinutes(0);
d.setSeconds(0);
d.setMilliseconds(0);
return d.getTime();
If the timezone offset values are different between client and server,
you are going to get issues translating back and forth.
However, this does lead to another problem: I want users around the
world to select dates in the DateField.format's timezone. ie if a user
in Mumbai selects 01/07/2011, I want that to mean 01/07/2011 in
Australia/Brisbane time.
So instead of changing the format's timezone, I need to offset the
time long sent to and from the client by the client's timezone offset.
Therefore I need to patch DateField.js and DateField.java to take this
into account.
To summarise however, the current implementation of DateField is not
multi-timezone safe, and should be fixed.
Regards, Paul.
On 12/07/2011 8:45 AM, Paul Stanton wrote:
Sorry, I need to clarify the steps to reproduce:
If load the page with a null value, the first selection from the
widget works fine (ie 01/07/2011).
If you use the widget again to select the same date, it doesn't work,
the field now contains 02/07/2011.
Regards, Paul.
On 12/07/2011 12:44 PM, Paul Stanton wrote:
Hi all,
Tapestry 5.1...
I've run into a problem with the datefield component and am about to
look into patching it, but if anyone can offer some advice it would
be appreciated.
Our server is running in "Australia/Brisbane" timezone and some of
our clients are in the "India/Mumbai" timezone.
The problem is, when the clients select July 1, the input field is
populated with July 2. Selecting July 1 again results in July 3 in
the input field.
If this sounds familiar, please reply.
Regards, Paul.
//
---------------------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
