You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tapestry.apache.org by "Paul Stanton (JIRA)" <ji...@apache.org> on 2011/07/12 09:08:00 UTC
[jira] [Created] (TAP5-1575) DateField is not multi-timezone safe
DateField is not multi-timezone safe
------------------------------------
Key: TAP5-1575
URL: https://issues.apache.org/jira/browse/TAP5-1575
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.1.0.5
Reporter: Paul Stanton
Priority: Critical
If the client is in a different timezone to the server, selecting a date will set the wrong value in the input field in most cases.
The cause is the use of 'milliseconds since epoch'.
The following demonstrates part of the problem:
TimeZone serverTz = TimeZone.getTimeZone("GMT+1000");
TimeZone clientTz = TimeZone.getTimeZone("GMT-1500");
// simulates client to server communication method used by DateField
TimeZone.setDefault(serverTz);
SimpleDateFormat serverDf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
SimpleDateFormat clientDf = (SimpleDateFormat) serverDf.clone();
clientDf.setTimeZone(clientTz);
String dateSelection = "2011-07-01 00:00:00";
Date clientDate = clientDf.parse(dateSelection);
Date serverDate = new Date(clientDate.getTime());
System.out.println("2011-07-01 00:00:00 = " + serverDf.format(serverDate) + "?");
So if a user selected July 7 2011, the field would display July 2 2011 if the timezones were as above.
My solution was to remove the usage of both the java and javascript `Date.getTime` and `new Date(time)` functions. Instead, I serialise to "yyyy-MM-dd" and format/parse this on the server using the same tz as the format parameter.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1575) DateField is not multi-timezone safe
Posted by "Bob Harner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066671#comment-13066671 ]
Bob Harner commented on TAP5-1575:
----------------------------------
This issue looks like a duplicate of TAP5-841
> DateField is not multi-timezone safe
> ------------------------------------
>
> Key: TAP5-1575
> URL: https://issues.apache.org/jira/browse/TAP5-1575
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.1.0.5
> Reporter: Paul Stanton
> Priority: Critical
> Labels: DateField, TimeZone
>
> If the client is in a different timezone to the server, selecting a date will set the wrong value in the input field in most cases.
> The cause is the use of 'milliseconds since epoch'.
> The following demonstrates part of the problem:
> TimeZone serverTz = TimeZone.getTimeZone("GMT+1000");
> TimeZone clientTz = TimeZone.getTimeZone("GMT-1500");
> // simulates client to server communication method used by DateField
> TimeZone.setDefault(serverTz);
> SimpleDateFormat serverDf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
> SimpleDateFormat clientDf = (SimpleDateFormat) serverDf.clone();
> clientDf.setTimeZone(clientTz);
> String dateSelection = "2011-07-01 00:00:00";
> Date clientDate = clientDf.parse(dateSelection);
> Date serverDate = new Date(clientDate.getTime());
> System.out.println("2011-07-01 00:00:00 = " + serverDf.format(serverDate) + "?");
> So if a user selected July 7 2011, the field would display July 2 2011 if the timezones were as above.
> My solution was to remove the usage of both the java and javascript `Date.getTime` and `new Date(time)` functions. Instead, I serialise to "yyyy-MM-dd" and format/parse this on the server using the same tz as the format parameter.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TAP5-1575) DateField is not multi-timezone safe
Posted by "Paul Stanton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul Stanton closed TAP5-1575.
------------------------------
Resolution: Duplicate
dup of TAP5-841
> DateField is not multi-timezone safe
> ------------------------------------
>
> Key: TAP5-1575
> URL: https://issues.apache.org/jira/browse/TAP5-1575
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.1.0.5
> Reporter: Paul Stanton
> Priority: Critical
> Labels: DateField, TimeZone
>
> If the client is in a different timezone to the server, selecting a date will set the wrong value in the input field in most cases.
> The cause is the use of 'milliseconds since epoch'.
> The following demonstrates part of the problem:
> TimeZone serverTz = TimeZone.getTimeZone("GMT+1000");
> TimeZone clientTz = TimeZone.getTimeZone("GMT-1500");
> // simulates client to server communication method used by DateField
> TimeZone.setDefault(serverTz);
> SimpleDateFormat serverDf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
> SimpleDateFormat clientDf = (SimpleDateFormat) serverDf.clone();
> clientDf.setTimeZone(clientTz);
> String dateSelection = "2011-07-01 00:00:00";
> Date clientDate = clientDf.parse(dateSelection);
> Date serverDate = new Date(clientDate.getTime());
> System.out.println("2011-07-01 00:00:00 = " + serverDf.format(serverDate) + "?");
> So if a user selected July 7 2011, the field would display July 2 2011 if the timezones were as above.
> My solution was to remove the usage of both the java and javascript `Date.getTime` and `new Date(time)` functions. Instead, I serialise to "yyyy-MM-dd" and format/parse this on the server using the same tz as the format parameter.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TAP5-1575) DateField is not multi-timezone safe
Posted by "Bob Harner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066671#comment-13066671 ]
Bob Harner commented on TAP5-1575:
----------------------------------
This issue looks like a duplicate of TAP5-841
> DateField is not multi-timezone safe
> ------------------------------------
>
> Key: TAP5-1575
> URL: https://issues.apache.org/jira/browse/TAP5-1575
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.1.0.5
> Reporter: Paul Stanton
> Priority: Critical
> Labels: DateField, TimeZone
>
> If the client is in a different timezone to the server, selecting a date will set the wrong value in the input field in most cases.
> The cause is the use of 'milliseconds since epoch'.
> The following demonstrates part of the problem:
> TimeZone serverTz = TimeZone.getTimeZone("GMT+1000");
> TimeZone clientTz = TimeZone.getTimeZone("GMT-1500");
> // simulates client to server communication method used by DateField
> TimeZone.setDefault(serverTz);
> SimpleDateFormat serverDf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
> SimpleDateFormat clientDf = (SimpleDateFormat) serverDf.clone();
> clientDf.setTimeZone(clientTz);
> String dateSelection = "2011-07-01 00:00:00";
> Date clientDate = clientDf.parse(dateSelection);
> Date serverDate = new Date(clientDate.getTime());
> System.out.println("2011-07-01 00:00:00 = " + serverDf.format(serverDate) + "?");
> So if a user selected July 7 2011, the field would display July 2 2011 if the timezones were as above.
> My solution was to remove the usage of both the java and javascript `Date.getTime` and `new Date(time)` functions. Instead, I serialise to "yyyy-MM-dd" and format/parse this on the server using the same tz as the format parameter.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (TAP5-1575) DateField is not multi-timezone safe
Posted by "Paul Stanton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul Stanton closed TAP5-1575.
------------------------------
Resolution: Duplicate
dup of TAP5-841
> DateField is not multi-timezone safe
> ------------------------------------
>
> Key: TAP5-1575
> URL: https://issues.apache.org/jira/browse/TAP5-1575
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.1.0.5
> Reporter: Paul Stanton
> Priority: Critical
> Labels: DateField, TimeZone
>
> If the client is in a different timezone to the server, selecting a date will set the wrong value in the input field in most cases.
> The cause is the use of 'milliseconds since epoch'.
> The following demonstrates part of the problem:
> TimeZone serverTz = TimeZone.getTimeZone("GMT+1000");
> TimeZone clientTz = TimeZone.getTimeZone("GMT-1500");
> // simulates client to server communication method used by DateField
> TimeZone.setDefault(serverTz);
> SimpleDateFormat serverDf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
> SimpleDateFormat clientDf = (SimpleDateFormat) serverDf.clone();
> clientDf.setTimeZone(clientTz);
> String dateSelection = "2011-07-01 00:00:00";
> Date clientDate = clientDf.parse(dateSelection);
> Date serverDate = new Date(clientDate.getTime());
> System.out.println("2011-07-01 00:00:00 = " + serverDf.format(serverDate) + "?");
> So if a user selected July 7 2011, the field would display July 2 2011 if the timezones were as above.
> My solution was to remove the usage of both the java and javascript `Date.getTime` and `new Date(time)` functions. Instead, I serialise to "yyyy-MM-dd" and format/parse this on the server using the same tz as the format parameter.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira