LocalDate equals method bug

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

LocalDate equals method bug

John Hanks
I was surprised when I was using the equals() method of the LocalDate class.

It was not behaving as I would expect.

Take a look at the code below:

      DateTimeFormatter dateTimeFormat = DateTimeFormat.forPattern("yyyyMMdd HH:mm");
      Calendar calendar = dateTimeFormat.parseDateTime("20120621 09:00").toCalendar(null);
      LocalDate localDate1 = new LocalDate(calendar);
      LocalDate localDate2 = new LocalDate(2012,6,21);      
      System.out.println(localDate1);
      System.out.println(localDate2);
      System.out.println("equals(): " + localDate1.equals(localDate2));
      System.out.println("isEqual(): " + localDate1.isEqual(localDate2));


The output is:

    2012-06-21
    2012-06-21
    equals(): false
    isEqual(): true


Why is the equals method comparison false.

Is this not a Joda bug?

P.S. I'm using Joda 2.1




------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LocalDate equals method bug

jodastephen
Print out the result of getChronology() for both, and see if they are
equal. I suspect they are different (equals depends on the chronology
- a design flaw in Joda-Time).
Stephen



On 27 June 2012 02:51, John Hanks <[hidden email]> wrote:

> I was surprised when I was using the equals() method of the LocalDate class.
>
> It was not behaving as I would expect.
>
> Take a look at the code below:
>
>       DateTimeFormatter dateTimeFormat = DateTimeFormat.forPattern("yyyyMMdd
> HH:mm");
>       Calendar calendar = dateTimeFormat.parseDateTime("20120621
> 09:00").toCalendar(null);
>       LocalDate localDate1 = new LocalDate(calendar);
>       LocalDate localDate2 = new LocalDate(2012,6,21);
>       System.out.println(localDate1);
>       System.out.println(localDate2);
>       System.out.println("equals(): " + localDate1.equals(localDate2));
>       System.out.println("isEqual(): " + localDate1.isEqual(localDate2));
>
>
> The output is:
>
>     2012-06-21
>     2012-06-21
>     equals(): false
>     isEqual(): true
>
>
> Why is the equals method comparison false.
>
> Is this not a Joda bug?
>
> P.S. I'm using Joda 2.1
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Joda-interest mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/joda-interest
>

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LocalDate equals method bug

John Hanks
In my previous example the output of getChronology() is shown below:

localDate1  -> GJChronology[UTC]
localDate2  -> ISOChronology[UTC]

That begs the question, why does the LocalDate class even care about the chronology?


On Wed, Jun 27, 2012 at 2:15 AM, Stephen Colebourne <[hidden email]> wrote:
Print out the result of getChronology() for both, and see if they are
equal. I suspect they are different (equals depends on the chronology
- a design flaw in Joda-Time).
Stephen



On 27 June 2012 02:51, John Hanks <[hidden email]> wrote:
> I was surprised when I was using the equals() method of the LocalDate class.
>
> It was not behaving as I would expect.
>
> Take a look at the code below:
>
>       DateTimeFormatter dateTimeFormat = DateTimeFormat.forPattern("yyyyMMdd
> HH:mm");
>       Calendar calendar = dateTimeFormat.parseDateTime("20120621
> 09:00").toCalendar(null);
>       LocalDate localDate1 = new LocalDate(calendar);
>       LocalDate localDate2 = new LocalDate(2012,6,21);
>       System.out.println(localDate1);
>       System.out.println(localDate2);
>       System.out.println("equals(): " + localDate1.equals(localDate2));
>       System.out.println("isEqual(): " + localDate1.isEqual(localDate2));
>
>
> The output is:
>
>     2012-06-21
>     2012-06-21
>     equals(): false
>     isEqual(): true
>
>
> Why is the equals method comparison false.
>
> Is this not a Joda bug?
>
> P.S. I'm using Joda 2.1
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Joda-interest mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/joda-interest
>

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LocalDate equals method bug

Matthew McCawley

John Hanks <[hidden email]> wrote on 06/27/2012 01:26:43 PM:
> In my previous example the output of getChronology() is shown below:

>
> localDate1  -> GJChronology[UTC]

> localDate2  -> ISOChronology[UTC]
>
> That begs the question, why does the LocalDate class even care about
> the chronology?


Equals: "Compares this ReadablePartial with another returning true if the chronology, field types and values are equal."
http://joda-time.sourceforge.net/apidocs/org/joda/time/LocalDate.html#equals(java.lang.Object) 

isEqual: "Is this partial the same as the specified partial."
http://joda-time.sourceforge.net/apidocs/org/joda/time/base/AbstractPartial.html#isEqual(org.joda.time.ReadablePartial) 
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LocalDate equals method bug

John Hanks
I understand the isEquals() method compares the chronology but the why does the LocalDate class equals method compare the chronology and why does it even care?

In my mind, a LocalDate class should not care what sort of chronology it was constructed with. If the year, month, and date match, it should be equals. Is there a flaw in that logic?

On Wed, Jun 27, 2012 at 10:54 AM, Matthew McCawley <[hidden email]> wrote:

John Hanks <[hidden email]> wrote on 06/27/2012 01:26:43 PM:


> In my previous example the output of getChronology() is shown below:

>
> localDate1  -> GJChronology[UTC]

> localDate2  -> ISOChronology[UTC]
>
> That begs the question, why does the LocalDate class even care about
> the chronology?


Equals: "Compares this ReadablePartial with another returning true if the chronology, field types and values are equal."
http://joda-time.sourceforge.net/apidocs/org/joda/time/LocalDate.html#equals(java.lang.Object) 

isEqual: "Is this partial the same as the specified partial."
http://joda-time.sourceforge.net/apidocs/org/joda/time/base/AbstractPartial.html#isEqual(org.joda.time.ReadablePartial) 


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LocalDate equals method bug

John Hanks
In reply to this post by jodastephen
I agree that comparing chronology in the equals() method for the LocalDate class is a design flaw (bug).

Are there any plans on fixing it?

I can see some pretty nasty bugs from this such as using LocalDate instances as keys in a Map. You might not get what you expect.

On Wed, Jun 27, 2012 at 2:15 AM, Stephen Colebourne <[hidden email]> wrote:
Print out the result of getChronology() for both, and see if they are
equal. I suspect they are different (equals depends on the chronology
- a design flaw in Joda-Time).
Stephen



On 27 June 2012 02:51, John Hanks <[hidden email]> wrote:
> I was surprised when I was using the equals() method of the LocalDate class.
>
> It was not behaving as I would expect.
>
> Take a look at the code below:
>
>       DateTimeFormatter dateTimeFormat = DateTimeFormat.forPattern("yyyyMMdd
> HH:mm");
>       Calendar calendar = dateTimeFormat.parseDateTime("20120621
> 09:00").toCalendar(null);
>       LocalDate localDate1 = new LocalDate(calendar);
>       LocalDate localDate2 = new LocalDate(2012,6,21);
>       System.out.println(localDate1);
>       System.out.println(localDate2);
>       System.out.println("equals(): " + localDate1.equals(localDate2));
>       System.out.println("isEqual(): " + localDate1.isEqual(localDate2));
>
>
> The output is:
>
>     2012-06-21
>     2012-06-21
>     equals(): false
>     isEqual(): true
>
>
> Why is the equals method comparison false.
>
> Is this not a Joda bug?
>
> P.S. I'm using Joda 2.1
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Joda-interest mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/joda-interest
>

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LocalDate equals method bug

jodastephen
2012-05-01 in ISO and 2012-05-01 in Coptic/Ethiopic/Hijra etc are
totally different dates on the time-line. You're only considering it
to be a problem because for GJ after the cutover date they happen to
represent the same date on the time-line.

Its a design flaw, because pluggable chronologies don't work for most
people as they don't realise the chronology field exists and is used
in most cases. The problem is made worse because the toString doesn't
show it. But there is zero chance of fixing it. Its not a bug, because
it works as originally intended and designed, its just that the design
is imperfect (and backwards compatibiilty prevents change).

ThreeTen/JSR-310 will have a different design approach, because of this issue.

The short answer is that you must control the chronology of the
dates/times you use.

Stephen


On 28 June 2012 01:51, John Hanks <[hidden email]> wrote:

> I agree that comparing chronology in the equals() method for the LocalDate
> class is a design flaw (bug).
>
> Are there any plans on fixing it?
>
> I can see some pretty nasty bugs from this such as using LocalDate instances
> as keys in a Map. You might not get what you expect.
>
> On Wed, Jun 27, 2012 at 2:15 AM, Stephen Colebourne <[hidden email]>
> wrote:
>>
>> Print out the result of getChronology() for both, and see if they are
>> equal. I suspect they are different (equals depends on the chronology
>> - a design flaw in Joda-Time).
>> Stephen
>>
>>
>>
>> On 27 June 2012 02:51, John Hanks <[hidden email]> wrote:
>> > I was surprised when I was using the equals() method of the LocalDate
>> > class.
>> >
>> > It was not behaving as I would expect.
>> >
>> > Take a look at the code below:
>> >
>> >       DateTimeFormatter dateTimeFormat =
>> > DateTimeFormat.forPattern("yyyyMMdd
>> > HH:mm");
>> >       Calendar calendar = dateTimeFormat.parseDateTime("20120621
>> > 09:00").toCalendar(null);
>> >       LocalDate localDate1 = new LocalDate(calendar);
>> >       LocalDate localDate2 = new LocalDate(2012,6,21);
>> >       System.out.println(localDate1);
>> >       System.out.println(localDate2);
>> >       System.out.println("equals(): " + localDate1.equals(localDate2));
>> >       System.out.println("isEqual(): " +
>> > localDate1.isEqual(localDate2));
>> >
>> >
>> > The output is:
>> >
>> >     2012-06-21
>> >     2012-06-21
>> >     equals(): false
>> >     isEqual(): true
>> >
>> >
>> > Why is the equals method comparison false.
>> >
>> > Is this not a Joda bug?
>> >
>> > P.S. I'm using Joda 2.1
>> >
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Live Security Virtual Conference
>> > Exclusive live event will cover all the ways today's security and
>> > threat landscape has changed and how IT managers can respond.
>> > Discussions
>> > will include endpoint security, mobile security and the latest in
>> > malware
>> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> > _______________________________________________
>> > Joda-interest mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/joda-interest
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Joda-interest mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Joda-interest mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/joda-interest
>

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LocalDate equals method bug

John Hanks
In my example I had have 2 LocalDates.

They both have the same toString() output:   2012-06-21

One uses GJChronology and the other ISOChronology.

Since the date "2012-06-21" represents the same time in both chronologies, why can't the equals() method return true for that date?


On Thu, Jun 28, 2012 at 1:02 AM, Stephen Colebourne <[hidden email]> wrote:
2012-05-01 in ISO and 2012-05-01 in Coptic/Ethiopic/Hijra etc are
totally different dates on the time-line. You're only considering it
to be a problem because for GJ after the cutover date they happen to
represent the same date on the time-line.

Its a design flaw, because pluggable chronologies don't work for most
people as they don't realise the chronology field exists and is used
in most cases. The problem is made worse because the toString doesn't
show it. But there is zero chance of fixing it. Its not a bug, because
it works as originally intended and designed, its just that the design
is imperfect (and backwards compatibiilty prevents change).

ThreeTen/JSR-310 will have a different design approach, because of this issue.

The short answer is that you must control the chronology of the
dates/times you use.

Stephen


On 28 June 2012 01:51, John Hanks <[hidden email]> wrote:
> I agree that comparing chronology in the equals() method for the LocalDate
> class is a design flaw (bug).
>
> Are there any plans on fixing it?
>
> I can see some pretty nasty bugs from this such as using LocalDate instances
> as keys in a Map. You might not get what you expect.
>
> On Wed, Jun 27, 2012 at 2:15 AM, Stephen Colebourne <[hidden email]>
> wrote:
>>
>> Print out the result of getChronology() for both, and see if they are
>> equal. I suspect they are different (equals depends on the chronology
>> - a design flaw in Joda-Time).
>> Stephen
>>
>>
>>
>> On 27 June 2012 02:51, John Hanks <[hidden email]> wrote:
>> > I was surprised when I was using the equals() method of the LocalDate
>> > class.
>> >
>> > It was not behaving as I would expect.
>> >
>> > Take a look at the code below:
>> >
>> >       DateTimeFormatter dateTimeFormat =
>> > DateTimeFormat.forPattern("yyyyMMdd
>> > HH:mm");
>> >       Calendar calendar = dateTimeFormat.parseDateTime("20120621
>> > 09:00").toCalendar(null);
>> >       LocalDate localDate1 = new LocalDate(calendar);
>> >       LocalDate localDate2 = new LocalDate(2012,6,21);
>> >       System.out.println(localDate1);
>> >       System.out.println(localDate2);
>> >       System.out.println("equals(): " + localDate1.equals(localDate2));
>> >       System.out.println("isEqual(): " +
>> > localDate1.isEqual(localDate2));
>> >
>> >
>> > The output is:
>> >
>> >     2012-06-21
>> >     2012-06-21
>> >     equals(): false
>> >     isEqual(): true
>> >
>> >
>> > Why is the equals method comparison false.
>> >
>> > Is this not a Joda bug?
>> >
>> > P.S. I'm using Joda 2.1
>> >
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Live Security Virtual Conference
>> > Exclusive live event will cover all the ways today's security and
>> > threat landscape has changed and how IT managers can respond.
>> > Discussions
>> > will include endpoint security, mobile security and the latest in
>> > malware
>> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> > _______________________________________________
>> > Joda-interest mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/joda-interest
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Joda-interest mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Joda-interest mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/joda-interest
>

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: LocalDate equals method bug

jodastephen
An equals method should always be consistent in its definition. Having
the chronology sometimes used and sometimes not would not be good.

All Joda-Time objects (and all imutable objects in general) should
have an equals method that is based on the entire state of the object
- and clearly the chronologies are different. They should also have a
toString exposing the entire state of the object, but sadly that isn't
the case.

If you want to compare two dates for date-on-time-line, use isEqual().

Stephen




On 28 June 2012 18:51, John Hanks <[hidden email]> wrote:

> In my example I had have 2 LocalDates.
>
> They both have the same toString() output:   2012-06-21
>
> One uses GJChronology and the other ISOChronology.
>
> Since the date "2012-06-21" represents the same time in both chronologies,
> why can't the equals() method return true for that date?
>
>
> On Thu, Jun 28, 2012 at 1:02 AM, Stephen Colebourne <[hidden email]>
> wrote:
>>
>> 2012-05-01 in ISO and 2012-05-01 in Coptic/Ethiopic/Hijra etc are
>> totally different dates on the time-line. You're only considering it
>> to be a problem because for GJ after the cutover date they happen to
>> represent the same date on the time-line.
>>
>> Its a design flaw, because pluggable chronologies don't work for most
>> people as they don't realise the chronology field exists and is used
>> in most cases. The problem is made worse because the toString doesn't
>> show it. But there is zero chance of fixing it. Its not a bug, because
>> it works as originally intended and designed, its just that the design
>> is imperfect (and backwards compatibiilty prevents change).
>>
>> ThreeTen/JSR-310 will have a different design approach, because of this
>> issue.
>>
>> The short answer is that you must control the chronology of the
>> dates/times you use.
>>
>> Stephen
>>
>>
>> On 28 June 2012 01:51, John Hanks <[hidden email]> wrote:
>> > I agree that comparing chronology in the equals() method for the
>> > LocalDate
>> > class is a design flaw (bug).
>> >
>> > Are there any plans on fixing it?
>> >
>> > I can see some pretty nasty bugs from this such as using LocalDate
>> > instances
>> > as keys in a Map. You might not get what you expect.
>> >
>> > On Wed, Jun 27, 2012 at 2:15 AM, Stephen Colebourne
>> > <[hidden email]>
>> > wrote:
>> >>
>> >> Print out the result of getChronology() for both, and see if they are
>> >> equal. I suspect they are different (equals depends on the chronology
>> >> - a design flaw in Joda-Time).
>> >> Stephen
>> >>
>> >>
>> >>
>> >> On 27 June 2012 02:51, John Hanks <[hidden email]> wrote:
>> >> > I was surprised when I was using the equals() method of the LocalDate
>> >> > class.
>> >> >
>> >> > It was not behaving as I would expect.
>> >> >
>> >> > Take a look at the code below:
>> >> >
>> >> >       DateTimeFormatter dateTimeFormat =
>> >> > DateTimeFormat.forPattern("yyyyMMdd
>> >> > HH:mm");
>> >> >       Calendar calendar = dateTimeFormat.parseDateTime("20120621
>> >> > 09:00").toCalendar(null);
>> >> >       LocalDate localDate1 = new LocalDate(calendar);
>> >> >       LocalDate localDate2 = new LocalDate(2012,6,21);
>> >> >       System.out.println(localDate1);
>> >> >       System.out.println(localDate2);
>> >> >       System.out.println("equals(): " +
>> >> > localDate1.equals(localDate2));
>> >> >       System.out.println("isEqual(): " +
>> >> > localDate1.isEqual(localDate2));
>> >> >
>> >> >
>> >> > The output is:
>> >> >
>> >> >     2012-06-21
>> >> >     2012-06-21
>> >> >     equals(): false
>> >> >     isEqual(): true
>> >> >
>> >> >
>> >> > Why is the equals method comparison false.
>> >> >
>> >> > Is this not a Joda bug?
>> >> >
>> >> > P.S. I'm using Joda 2.1
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > ------------------------------------------------------------------------------
>> >> > Live Security Virtual Conference
>> >> > Exclusive live event will cover all the ways today's security and
>> >> > threat landscape has changed and how IT managers can respond.
>> >> > Discussions
>> >> > will include endpoint security, mobile security and the latest in
>> >> > malware
>> >> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> >> > _______________________________________________
>> >> > Joda-interest mailing list
>> >> > [hidden email]
>> >> > https://lists.sourceforge.net/lists/listinfo/joda-interest
>> >> >
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Live Security Virtual Conference
>> >> Exclusive live event will cover all the ways today's security and
>> >> threat landscape has changed and how IT managers can respond.
>> >> Discussions
>> >> will include endpoint security, mobile security and the latest in
>> >> malware
>> >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> >> _______________________________________________
>> >> Joda-interest mailing list
>> >> [hidden email]
>> >> https://lists.sourceforge.net/lists/listinfo/joda-interest
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > Live Security Virtual Conference
>> > Exclusive live event will cover all the ways today's security and
>> > threat landscape has changed and how IT managers can respond.
>> > Discussions
>> > will include endpoint security, mobile security and the latest in
>> > malware
>> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> > _______________________________________________
>> > Joda-interest mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/joda-interest
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Joda-interest mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/joda-interest
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Joda-interest mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/joda-interest
>

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Joda-interest mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Loading...