[threeten-dev] Instant.with(TemporalField, long) does not throw ArithmeticException for numeric overflow error

[Patrick Zhang]

Hi Stephen,

Thanks, I will modify my test code to DateTimeException for such kind of 
scenarios. I will send out another mail for review.

And Here I have another question for adjustInto() method in 
java.time.temporal.TemporalAdjuster interface.

Actually, I am a bit confused by OffsetDateTime.adjustInto().
 From description in javadoc,
===============
The adjustment is equivalent to using Temporal.with(TemporalField, long) 
three times, passing ChronoField.OFFSET_SECONDS, ChronoField.EPOCH_DAY 
and ChronoField.NANO_OF_DAY as the fields.
===============

We can confirm OffsetDateTime.adjustInto(temporal) should work well if 
"temporal" object supports below 3 fileds:
OFFSET_SECONDS
EPOCH_DAY
NANO_OF_DAY

So I am trying to convert one OffsetDateTime to ZonedDateTime since it 
supports such 3 fields really:
============
                 ZoneId ZONE_PARIS = ZoneId.of("Europe/Paris");
                 ZoneId ZONE_GAZA = ZoneId.of("Asia/Gaza");
                 ZoneOffset OFFSET_PONE = ZoneOffset.ofHours(1);

                 OffsetDateTime t1 = 
OffsetDateTime.of(LocalDateTime.of(2012, 3, 4, 23, 5), OFFSET_PONE);
                 ZonedDateTime t2 = 
ZonedDateTime.of(LocalDateTime.of(2012, 3, 4, 1, 1, 1, 100), ZONE_GAZA) ;
                 ZonedDateTime t3 = (ZonedDateTime)(t1.adjustInto(t2)) ;
                 System.out.println(t1) ;
                 System.out.println(t2) ;
                 System.out.println(t3) ;
===========

The output is below:
===========
2012-03-04T23:05+01:00
2012-03-04T01:01:01.000000100+02:00[Asia/Gaza]
2012-03-04T23:05+02:00[Asia/Gaza]
===========

The date-time related fields are  "adjustInto" really. But it looks 
ZoneOffset do not change. It still keeps "+02:00".

Is it a bug? Personally I think the ZoneOffset should be modified to 
"+01:00" since OFFSET_SECONDS will be adjusted. :)

FYI,
When I adjust one OffsetDateTime to another OffsetDateTime, the 
ZoneOffset will be changed as javadoc description.

Regards
Patrick


On 2/18/13 5:46 AM, Stephen Colebourne wrote:
> On 17 February 2013 15:27, Patrick Zhang<patrick.zhang at oracle.com>  wrote:
>> I have found such a problem during creating new test code for
>> java.time.Instant.
>> It can be reproduced easily by below:
>>
>>                  Instant i1 = Instant.ofEpochSecond(1, -10) ;
>>                  Instant i3 = i1.with(ChronoField.NANO_OF_SECOND,
>> 1000000000L);
>>
>> As javadoc description, it should throw ArithmeticException since range of
>> NANO_OF_SECOND is 0-999999999.
>>
>> Actually it throws DateTimeException,
>> =======
>> Exception in thread "main" java.time.DateTimeException: Invalid value for
>> NanoOfSecond (valid values 0 - 999999999): 1000000000
>>      at java.time.temporal.ValueRange.checkValidValue(ValueRange.java:309)
>>      at java.time.temporal.ChronoField.checkValidValue(ChronoField.java:583)
>>      at java.time.Instant.with(Instant.java:632)
>>      at Test1.f1(Test1.java:14)
>>      at Test1.main(Test1.java:5)
>> =======
> DateTimeException is the correct error here.
>
> ArithmeticException is for numeric overflow, such as multiplying two
> numbers exceeds the capability of an int.
> DateTimeException includes general argument validity problems, like that above.
>
> Stephen