RFR JDK-5077522 : Duration.compare incorrect for some values
Lance @ Oracle
lance.andersen at oracle.com
Sat Jun 21 10:32:09 UTC 2014
Agree this is better and cleaner!
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com
Sent from my iPad
On Jun 21, 2014, at 4:27 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> Thanks Joe!
>
> This is much cleaner indeed :-)
>
> -- daniel
>
> On 6/21/14 4:36 AM, huizhe wang wrote:
>> Thanks Daniel, Lance.
>>
>> On 6/20/2014 3:02 AM, Daniel Fuchs wrote:
>>> Hi Joe,
>>>
>>> Thanks for the detailed explanation.
>>> It really helps reviewing the fix!
>>
>> Glad to know it helps. I thought this part of spec could be unfamiliar to people.
>>
>>>
>>> This looks reasonable to me. One minor nit is that you
>>> could turn:
>>>
>>> 769 BigInteger maxintAsBigInteger = BigInteger.valueOf((long) Integer.MAX_VALUE);
>>
>> Good catch! I was going to do so but then forgot.
>>
>> I also refactored the check method so that the checks can be done in one loop: 24 lines of code instead of the original 170. I feel good :-)
>>
>> The other changes are purely clean-up and in one case, JavaDoc.
>>
>> http://cr.openjdk.java.net/~joehw/jdk9/5077522/webrev/
>>
>> Best regards,
>> Joe
>>
>>
>>>
>>> into a static final constant in the class.
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>> On 6/17/14 9:19 PM, huizhe wang wrote:
>>>> Hi,
>>>>
>>>> This is a long time compatibility issue: Duration.compare returns equal
>>>> for INDETERMINATE relations defined in XML Schema standard
>>>> (http://www.w3.org/TR/xmlschema-2/#duration-order) as listed in the
>>>> following table:
>>>>
>>>> Relation
>>>> P*1Y* > P*364D* <> P*365D* <> P*366D* < P*367D*
>>>> P*1M* > P*27D* <> P*28D* <> P*29D* <> P*30D* <>
>>>> P*31D* < P*32D*
>>>> P*5M* > P*149D* <> P*150D* <> P*151D* <> P*152D* <>
>>>> P*153D* < P*154D*
>>>>
>>>>
>>>>
>>>> The order-relation of two Duratoin values x and y is x < y iff s+x < s+y
>>>> for each qualified datetime s listed below:
>>>>
>>>> * 1696-09-01T00:00:00Z
>>>> * 1697-02-01T00:00:00Z
>>>> * 1903-03-01T00:00:00Z
>>>> * 1903-07-01T00:00:00Z
>>>>
>>>>
>>>> The original implementation used Unix epoch, that is, 00:00:00 UTC on 1
>>>> January 1970, as s in the above calculation which violated the above
>>>> specification. A patch during JDK 6 development added correct
>>>> implementation of the spec, but it was unfortunately added after the
>>>> original calculation using Epoch time.
>>>>
>>>> *The fix to the issue therefore is simply removing the calculation using
>>>> Epoch time.* I also consolidated the tedious max field value checks into
>>>> a method called checkMaxValue.
>>>>
>>>> *Patch:*
>>>> http://cr.openjdk.java.net/~joehw/jdk9/5077522/webrev/
>>>>
>>>> Test:
>>>> testCompareWithInderterminateRelation: this is a copy of the JCK test
>>>> that tests INDETERMINATE relations.
>>>> testVerifyOtherRelations: this is added to verify edge cases, e.g. +- 1
>>>> second to the original test cases. For example, to the original test:
>>>> PT525600M is P365D <> P1Y, I added "PT525599M59S", "<", "P1Y", and
>>>> PT527040M -> P366D <> P1Y, "PT527040M1S", ">", "P1Y"
>>>>
>>>> Below is the test result:
>>>> Comparing P1Y and P365D: INDETERMINATE
>>>> Comparing P1Y and P366D: INDETERMINATE
>>>> Comparing P1M and P28D: INDETERMINATE
>>>> Comparing P1M and P29D: INDETERMINATE
>>>> Comparing P1M and P30D: INDETERMINATE
>>>> Comparing P1M and P31D: INDETERMINATE
>>>> Comparing P5M and P150D: INDETERMINATE
>>>> Comparing P5M and P151D: INDETERMINATE
>>>> Comparing P5M and P152D: INDETERMINATE
>>>> Comparing P5M and P153D: INDETERMINATE
>>>> Comparing PT2419200S and P1M: INDETERMINATE
>>>> Comparing PT2678400S and P1M: INDETERMINATE
>>>> Comparing PT31536000S and P1Y: INDETERMINATE
>>>> Comparing PT31622400S and P1Y: INDETERMINATE
>>>> Comparing PT525600M and P1Y: INDETERMINATE
>>>> Comparing PT527040M and P1Y: INDETERMINATE
>>>> Comparing PT8760H and P1Y: INDETERMINATE
>>>> Comparing PT8784H and P1Y: INDETERMINATE
>>>> Comparing P365D and P1Y: INDETERMINATE
>>>> Comparing P1Y and P364D: expected: GREATER actual: GREATER
>>>> Comparing P1Y and P367D: expected: LESSER actual: LESSER
>>>> Comparing P1Y2D and P366D: expected: GREATER actual: GREATER
>>>> Comparing P1M and P27D: expected: GREATER actual: GREATER
>>>> Comparing P1M and P32D: expected: LESSER actual: LESSER
>>>> Comparing P1M and P31DT1H: expected: LESSER actual: LESSER
>>>> Comparing P5M and P149D: expected: GREATER actual: GREATER
>>>> Comparing P5M and P154D: expected: LESSER actual: LESSER
>>>> Comparing P5M and P153DT1H: expected: LESSER actual: LESSER
>>>> Comparing PT2419199S and P1M: expected: LESSER actual: LESSER
>>>> Comparing PT2678401S and P1M: expected: GREATER actual: GREATER
>>>> Comparing PT31535999S and P1Y: expected: LESSER actual: LESSER
>>>> Comparing PT31622401S and P1Y: expected: GREATER actual: GREATER
>>>> Comparing PT525599M59S and P1Y: expected: LESSER actual: LESSER
>>>> Comparing PT527040M1S and P1Y: expected: GREATER actual: GREATER
>>>> Comparing PT8759H59M59S and P1Y: expected: LESSER actual: LESSER
>>>> Comparing PT8784H1S and P1Y: expected: GREATER actual: GREATER
>>>>
>>>> Number of tests passed: 36
>>>> Number of tests failed: 0
>>>>
>>>> Thanks,
>>>> Joe
>
More information about the core-libs-dev
mailing list