You are viewing a plain text version of this content. The canonical link for it is here.
Posted to savan-dev@ws.apache.org by "Amila Chinthaka Suriarachchi (JIRA)" <ji...@apache.org> on 2010/05/09 08:07:51 UTC
[jira] Commented: (AXIS2-4061) ConverterUtil converts time
incorrectly if millisecond part is over 7-digit long with value greater
than 2147483
[ https://issues.apache.org/jira/browse/AXIS2-4061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12865547#action_12865547 ]
Amila Chinthaka Suriarachchi commented on AXIS2-4061:
-----------------------------------------------------
already fix the issue using long data type
> ConverterUtil converts time incorrectly if millisecond part is over 7-digit long with value greater than 2147483
> ----------------------------------------------------------------------------------------------------------------
>
> Key: AXIS2-4061
> URL: https://issues.apache.org/jira/browse/AXIS2-4061
> Project: Axis2
> Issue Type: Bug
> Components: adb
> Affects Versions: 1.4.1, 1.4, nightly
> Environment: All platforms
> Reporter: Wah Yim
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Consider the following time in an XML message:
> 2008-10-02T13:12:11.2147484Z
> (Interpreted as October 2, 2008 at 1:12:11pm UTC, millsecond fraction = 214.7484ms)
> The org.apache.axis2.databinding.utils.ConverterUtil class' convertToDateTime(java.lang.String) method is called for parsing the XML datetime into a java.util.Calendar object. The following code is responsible for trimming the millisecond part down to 3-digit long:
> ========================================
> int miliSecond = 0;
> ...
> int milliSecondPartLength = 0;
> if (source.length() > 19) {
> String rest = source.substring(19);
> if (rest.startsWith(".")) {
> // i.e this have the ('.'s+) part
> if (rest.endsWith("Z")) {
> // this is in gmt time zone
> timeZoneOffSet = 0;
> calendar.setTimeZone(TimeZone.getTimeZone("GMT"));
> miliSecond = Integer.parseInt(rest.substring(1, rest.lastIndexOf("Z")));
> milliSecondPartLength = rest.substring(1,rest.lastIndexOf("Z")).trim().length();
> } else if ((rest.lastIndexOf("+") > 0) || (rest.lastIndexOf("-") > 0)) {
> ...
> }
> } else {
> ...
> }
> }
> ...
> if (milliSecondPartLength != 3){
> // milisecond part represenst the fraction of the second so we have to
> // find the fraction and multiply it by 1000. So if milisecond part
> // has three digits nothing required
> miliSecond = miliSecond * 1000;
> for (int i = 0; i < milliSecondPartLength; i++) {
> miliSecond = miliSecond / 10;
> }
> }
> calendar.set(Calendar.MILLISECOND, miliSecond);
> ========================================
> The code block "if (milliSecondPartLength != 3){..." above would multiple miliSecond by 1000 and then divide it by 10 for each millisecond digit part, eventually yielding the integer value of the millisecond down to a 3-digit part. The problem arises when the millisecond fraction is 7-digit or longer with a value greater than 2147483. In the example, with miliSecond = 2147484, miliSecond * 1000 would yield 2,147,484,000, which exceeds the 32-bit java int upper bound of 2,147,483,647, hence it is evaluated as -2,147,483,296 instead. The negative value of the millisecond part would result in an incorrect value of the final java.util.Calendar object.
> A potential fix would be defining the miliSecond variable as a "long" instead of "int". That would at least accommodate a 16-digit millisecond part with the maximum value of 9223372036854775. Or, a different algorithm should be considered to strip a millisecond part with length > 3 down to 3-digit long.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org