[threeten-dev] jdk bug in OffsetDateTime.INSTANT_COMPARATOR

Patrick Zhang patrick.zhang at oracle.com
Mon May 20 19:21:00 PDT 2013


Hi Roger,

I have submitted https://jbs.oracle.com/bugs/browse/JDK-8014939 for it.

Regards
Patrick

On 5/20/13 12:38 PM, Patrick Zhang wrote:
> Hi Team,
>
> It looks one bug in java.time.OffsetDateTime. The return value of 
> compareTo() and OffsetDateTime.INSTANT_COMPARATOR.compare() are 
> different.
> Sample code:
> ========
> OffsetDateTime a = OffsetDateTime.of(2008, 6, 30, 11, 20, 40, 4, 
> ZoneOffset.ofHours(2));
> OffsetDateTime b = OffsetDateTime.of(2008, 6, 30, 10, 20, 40, 5, 
> ZoneOffset.ofHours(1));
> System.out.println(a.compareTo(b));
> System.out.println(OffsetDateTime.INSTANT_COMPARATOR.compare(a, b));
> ========
>
> Output:
> ========
> -1
> 1
> ========
>
> I do not think it makes sense. The correct value should be a<b.
>
>  And it looks the implementation of INSTANT_COMPARATOR is incorrect:
> =========
>     public static final Comparator<OffsetDateTime> INSTANT_COMPARATOR 
> = new Comparator<OffsetDateTime>() {
>         @Override
>         public int compare(OffsetDateTime datetime1, OffsetDateTime 
> datetime2) {
>             int cmp = Long.compare(datetime1.toEpochSecond(), 
> datetime2.toEpochSecond());
>             if (cmp == 0) {
>                 cmp = 
> Long.compare(datetime1.toLocalTime().toNanoOfDay(), 
> datetime2.toLocalTime().toNanoOfDay());
>             }
>             return cmp;
>         }
>     };
> =========
>
> I think we can not compare localTime part of OffsetDateTime directly.
> It should be convert to Instant firstly. Then compare epochSecond and 
> nanoOfSecond.....
>
> Regards
> Patrick
>


More information about the threeten-dev mailing list