Stephen, Roger,
Thanks for the comments.
On 7/1/2016 7:11 PM, Roger Riggs wrote:
Never mind, I just saw the comment in the bug.
"Just for a reference, EpochDay range = (LocalDate.MIN.toEpochDay() ,
LocalDate.MAX.toEpochDay()) "
That comment is worth adding to the comments for EpochDay.
Please see the updated webrev
http://cr.openjdk.java.net/~bgopularam/ntv/8160681/webrev.01/
Thanks and regards,
Nadeesh TV
Roger
On 7/1/2016 9:38 AM, Roger Riggs wrote:
Hi Stephen,
I'm a bit puzzled by the values recommended for the EpochDay Range.
The code should be commented with the computation relative to the
range of year MIN/MAX
so there is a more complete understanding.
I would expect the MIN to be the negative of the MAX or pretty close.
Are the new values defined to avoid overflow in some computation?
Changing the valid range of values has a (nearly insignificant)
compatibility risk.
Thanks, Roger
On 7/1/2016 8:23 AM, Stephen Colebourne wrote:
Fine by me, thanks
Stephen
On 1 July 2016 at 12:38, nadeesh tv <nadeesh...@oracle.com> wrote:
Hi all,
Bug Id : https://bugs.openjdk.java.net/browse/JDK-8160681
Issue: Epoch day parameter to LocalDate.ofEpochDay() was not
validating
Webrev: http://cr.openjdk.java.net/~bgopularam/ntv/8160681/webrev.00/
Tests are already covered under factory_ofEpochDay_aboveMax() ,
factory_ofEpochDay_belowMin() .
Error was obscured. It was throwing DateTimeException because of
internally calculated YEAR was going out of range. Now it will throw
exception due to expected issue 'epoch day is out of range'.
--
Thanks and Regards,
Nadeesh TV
--
Thanks and Regards,
Nadeesh TV
