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

[Patrick Zhang]

I know each valid zoneId should have one fixed ZoneOffset. So it makes 
sense to me that ZoneOffset keeps "+2:00".
But from description of OffsetDateTime.adjustInto(), there is some conflict.

Regards
Patrick

On 2/18/13 8:20 PM, Patrick Zhang wrote:
> 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