You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Jukka Zitting (JIRA)" <ji...@apache.org> on 2006/10/24 09:48:17 UTC

[jira] Updated: (JCR-598) DateValue.equals() relies on Calendar.equals()

     [ http://issues.apache.org/jira/browse/JCR-598?page=all ]

Jukka Zitting updated JCR-598:
------------------------------

    Attachment: DateValue.patch

You're right, the comparison is incorrect.

The attached patch should fix the issue. We might also want to add a test case for this.

> DateValue.equals() relies on Calendar.equals()
> ----------------------------------------------
>
>                 Key: JCR-598
>                 URL: http://issues.apache.org/jira/browse/JCR-598
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: core
>            Reporter: angela
>         Attachments: DateValue.patch
>
>
> JSR170 states regarding Date values:
> "The text format of dates must follow the following ISO 8601:2000-compliant format".
> While DateValue.valueOf(String) and DateValue.getString() both rely on the functionality provided by the org.apache.jackrabbit.util.ISO8601, DateValue.equals() compares the equality of the internal Calendar object (DateValue line 89). This may return false even if the Iso-format of both values are equal.
> In other words: Creating a new DateValue using the ValueFactory from the String representation of an existing DateValue will return an object, that is not equal to the original DateValue. The reason for this is, that the String does not contain all infomation, that is used during Calendar.equals.
> regards
> angela

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira