SONARJAVA-6328 - Implement S8688: Time-based .now() methods should specify a ZoneId or a Clock

[NoemieBenard]

No description provided.

[hashicorp-vault-sonar-prod]

SONARJAVA-6328

[sonar-review-alpha]

Summary

This PR implements rule S8688, which detects calls to .now() without parameters on Java 8+ java.time API classes (LocalDate, LocalDateTime, LocalTime, MonthDay, OffsetDateTime, OffsetTime, Year, YearMonth, ZonedDateTime).

Why it matters: Relying on the system's default timezone can cause inconsistent behavior across different deployment environments (developer machine, CI, production). Explicitly passing a ZoneId or Clock makes the intent clear and ensures consistent behavior.

Implementation: The check extends AbstractMethodDetection to match parameterless .now() calls on the 9 target classes, reporting a single issue at the method name. Instant.now() is intentionally excluded since Instant doesn't store timezone information. The rule is added to the Sonar_way_profile (enabled by default) with "Major" severity.

What reviewers should know

Start with:

• NowWithoutParametersCheck.java — The core check implementation (51 lines, straightforward MethodMatchers pattern)
• NowWithoutParametersCheckSample.java — Test sample showing noncompliant calls and compliant fixes

Key design decisions:

• No Instant flag: Instant.now() is not flagged because Instant doesn't store timezone info; this is correct per the rule's intent
• 9 target classes: Explicitly listed in the MethodMatchers; LocalDate/Time variants are included even though they don't store timezone, because their .now() methods still depend on the system default to determine "now"
• Single issue location: Issues point to the method name ("now"), making the fix location clear

What to verify:

1. MethodMatchers pattern correctly targets only no-argument calls (.addWithoutParametersMatcher())
2. Test cases cover edge cases (nested calls in print statements, chained method calls, etc.)
3. Rule documentation is clear about why LocalDate/LocalTime are included despite not storing timezone
4. Integration tests pass (ruling test data files show expected findings in real projects)

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

[aurelien-coet-sonarsource]

If you extend the AbstractMethodDetection class, you can override getMethodInvocationMatchers method which will trigger the rule on invocations of specific method matchers. Then, instead of calling visitNode and explicitly having to check that the node is a MethodInvocationTree, you can override the onMethodInvocationFound method and directly raise the issue without the need for the condition.

[aurelien-coet-sonarsource]

The call to NOW_MATCHER.matches(mit) is unnecessary here: the method will only be called on method invocations that match the method matchers returned by getMethodInvocationMatchers(). You also know that the method will only ever be invoked on method calls where methodSelect will be a MemberSelectExpressionTree, so you could do something like:

Suggested change

	if (NOW_MATCHER.matches(mit) && mit.methodSelect() instanceof MemberSelectExpressionTree mset) {
	reportIssue(mset.identifier(), mit, "Explicitly specify the time zone by passing a ZoneId or a Clock to the .now() method.");
	}
	reportIssue(((MemberSelectExpressionTree) mit.methodSelect()).identifier(), mit, "Explicitly specify the time zone by passing a ZoneId or a Clock to the .now() method.");

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[sonar-review-alpha]

LGTM! ✅

🗣️ Give feedback

[aurelien-coet-sonarsource]

LGTM