[threeten-dev] Please help to review new test cases for java.time.OffsetDateTime

[roger riggs]

Hi Patrick,

These look fine.

Except for the Fixed clock there is no reasonable (TCK) test between
    clock.instant().getEpochSecond() and clock.millis()

Since there are no guarantees about the timeline being monotonic or steady.

As an implementation test it might make sense if the implementation made
some guarantees.
For now, the clock is the underlying os clock which does not make 
guarantees.

Roger

BTW, the jbs.oracle.com links are not visible outside of Oracle.
Links to the issues on bugs.sun.com would be better but do not currently 
work
correctly.

On 5/24/2013 4:34 AM, Patrick Zhang wrote:
> Hi Team,
>
> One simple modification because of below 2 bugs in OffsetDateTime
> https://jbs.oracle.com/bugs/browse/JDK-8015293
> https://jbs.oracle.com/bugs/browse/JDK-8014939
>
> 1. Apply OffsetDateTime.timeLineOrder() to all related compare() test.
> 2. Add one simple verification for clock.millis(). Since Clock 
> provides access to the "current" instant, I guess it may return 
> different value for clock.instant().getEpochSecond() and 
> clock.millis() especially if test machine is very very slow. The best 
> test strategy is setup one minor tolerance between the two values. As 
> one simple checking, here I only check it for fixed clock since it 
> always returns same instant.
>
> webrev:
> http://cr.openjdk.java.net/~pzhang/JSR310/java/time/OffsetDateTime/webrev/ 
>
>
> result:
> http://cr.openjdk.java.net/~pzhang/JSR310/java/time/OffsetDateTime/TCKClock_Fixed.jtr 
>
> http://cr.openjdk.java.net/~pzhang/JSR310/java/time/OffsetDateTime/TCKOffsetDateTime.jtr 
>
>
> Regards
> Patrick