java.time.Instant calculation traps

Rules and Languages New rules / language support
1
  • description of the Rule.

This rule will show calculations on java.time.Instant which will fail with a runtime exception, because it tries to plus/minus WEEKS, MONTHS, YEARS, DECADES. See java/time/Instant.java:851 .

The 2nd part (or 2nd rule?) can be a configuration option in my opinion. Plus and minus of DAYS are allowed, but they will add 24 hours and don’t take e.g. DST into account. This might be wanted behavior. Yet I expect that in cases you want to add day(s) that DST and timezone matters so that the wall clock time stays the same.

  • snippet of Noncompliant Code

java.time.Instant.now().plus(1,WEEKS)

java.time.Instant.now().minus(6,MONTHS)

  • snippet of Compilant Code (fixing the above noncompliant code)

Instant.now().minus(6,MINUTES)

//calculate using ZonedDateTime instead

ZonedDateTime.*now*().minusMonths(6).toInstant()

ZonedDateTime.*now*().minusWeeks(6).toInstant()

  • exceptions to the Noncompliant Code, i.e. conditions in which the noncompliant code should not raise an issue so that we reduce the number of False Positives.

As Instant does not know about any calendar system WEEKS, MONTHS, YEARS, DECADES are unknown. So afaik there are no exceptions.

  • external references and/or language specifications
  • type : Bug, Vulnerability, Code Smell, Security Hotspot?

Bug

  • Tags
    I don’t know

I don’t know if other topics/methods are having the same issue.

5

Thank you for these suggestions! Date and time operations are a common source of errors and such rules have been on our radar (sonar?) for a while.

I created SONARJAVA-5359 and SONARJAVA-5360 to track these issues.

1 Like