[threeten-dev] jdk bug in OffsetDateTime.INSTANT_COMPARATOR

[roger riggs]

Hi Patrick,

Yes, that seems like a bug to me as well.

Please file an issue in JBS to track it.  Having reached/reaching the M7 
milestone
the release managers need to be able to track progress and bugs in JBS.

I will mirror/move the Github issues to JBS this week.

Roger

On 5/20/2013 12:38 AM, 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
>