Ping, Reviewer needed for these minor updates, the test is now more
robust thanks to Peter's nudging.
http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/
Please review for two corrections:
- The java/time/tck/java/time/TCKLocalTime test failed on a slow
runtime due to -Xcomp;
Looks fine; cheers,
-Joe
On 9/13/2013 12:07 PM, roger riggs wrote:
Ping, Reviewer needed for these minor updates, the test is now more
robust thanks to Peter's nudging.
http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/
Please review for two corrections:
- The
looks fine.
On 9/13/13 12:07 PM, roger riggs wrote:
Ping, Reviewer needed for these minor updates, the test is now more
robust thanks to Peter's nudging.
http://cr.openjdk.java.net/~rriggs/webrev-localtime-now-8023639/
Please review for two corrections:
- The
On 09/09/2013 09:42 PM, roger riggs wrote:
Hi Peter,
Right, max doesn't solve the issue but I'm not keen on a test that
retries
until it gets a better answer.
Hi Roger,
If java.time logic is correct, it should only ever retry once when
roll-over or DST jump-back happens, so the test could
Hi Peter,
Point taken about the edge cases, I'm not sure it will occur in practice
but I updated the test to retry if the time changes by more than 15 minutes.
There are likely to be other existing tests that do not taken into account
DST changes but it is not a high priority now to find and fix
Hi Roger,
Sorry to be persistent, but if the LocalTime.now() returns local time
for a time zone that is not the default time zone (which is an error in
java.time implementation that I assume the test is trying to catch) then
the diff can be a constant 15 minutes and the loop will roll
Hi Peter,
Love those pathological edge cases...
On 9/10/2013 12:18 PM, Peter Levart wrote:
Hi Roger,
Sorry to be persistent, but if the LocalTime.now() returns local time
for a time zone that is not the default time zone (which is an error
in java.time implementation that I assume the test
On 09/06/2013 07:58 PM, roger riggs wrote:
Please review for two corrections:
- The java/time/tck/java/time/TCKLocalTime test failed on a slow
machine;
the test should be more lenient. The test is not appropriate for
a conformance test
and is moved to
Hi David,
I found even on my VirturalBox machine it frequently came close to the
.1ms target
and failed in one case. Raising the time was to reduce/prevent
intermittent failures.
Are other timing tests also sensitive to the Xcomp, how should tests be
written
to be insensitive to that JVM
Hi Peter,
The possible wrap-around caused by crossing midnight is handled by Math.max
so a retry is not needed.
Math.abs(test.toNanoOfDay() - expected.toNanoOfDay())
Thanks, Roger
On 9/9/2013 2:14 AM, Peter Levart wrote:
On 09/06/2013 07:58 PM, roger riggs wrote:
Please review for two
On 09/09/2013 03:12 PM, roger riggs wrote:
Hi Peter,
The possible wrap-around caused by crossing midnight is handled by
Math.max
so a retry is not needed.
Math.abs(test.toNanoOfDay() - expected.toNanoOfDay())
Hi Roger,
In case there is a wrap-around, the 'diff' is much more than
On 09/09/2013 05:14 PM, Peter Levart wrote:
On 09/09/2013 03:12 PM, roger riggs wrote:
Hi Peter,
The possible wrap-around caused by crossing midnight is handled by
Math.max
so a retry is not needed.
Math.abs(test.toNanoOfDay() - expected.toNanoOfDay())
Hi Roger,
In case there is a
Hi Peter,
Right, max doesn't solve the issue but I'm not keen on a test that retries
until it gets a better answer.
Adding nanosPerDay if the difference comes out negative would adjust
for the crossing of midnight and not require looping on a more complex
test condition.
The longish delay in
Hi Roger,
On 9/09/2013 10:48 PM, roger riggs wrote:
Hi David,
I found even on my VirturalBox machine it frequently came close to the
.1ms target
and failed in one case. Raising the time was to reduce/prevent
intermittent failures.
Are other timing tests also sensitive to the Xcomp, how
Typo:
+ assertTrue(diff 1); // less than 0.5 secs
David
On 10/09/2013 5:42 AM, roger riggs wrote:
Hi Peter,
Right, max doesn't solve the issue but I'm not keen on a test that retries
until it gets a better answer.
Adding nanosPerDay if the difference comes out negative
Hi Roger,
On 7/09/2013 3:58 AM, roger riggs wrote:
Please review for two corrections:
- The java/time/tck/java/time/TCKLocalTime test failed on a slow machine;
the test should be more lenient. The test is not appropriate for
a conformance test
and is moved to
Please review for two corrections:
- The java/time/tck/java/time/TCKLocalTime test failed on a slow machine;
the test should be more lenient. The test is not appropriate for
a conformance test
and is moved to java/time/test/java/time/TestLocalTime.
- The javadoc for the
17 matches
Mail list logo
