SOQL query filters on a hardcoded date literal
ID |
apex.maintainability.soql_hardcoded_date |
Severity |
high |
Remediation Complexity |
trivial |
Remediation Risk |
low |
Remediation Effort |
low |
Resource |
Api Usage |
Language |
Apex |
Description
Reports a date or datetime literal written directly into a SOQL query (2026-01-01, 2026-01-01T00:00:00Z).
Rationale
A date written into the query is correct on the day it is deployed and silently wrong every day after. Nothing fails: the query still runs, still returns rows, and still populates the report - it just answers a question about a fixed point in the past while everyone reading the result assumes it answers one about now. That is the worst failure mode a query can have, because there is no exception, no empty result and no log entry to notice.
The following code illustrates the pattern detected by this rule:
public class RenewalReport {
public List<Opportunity> closedThisYear() {
// FLAGGED: SOQL query filters on a hardcoded date literal
return [SELECT Id, Name FROM Opportunity WHERE CloseDate >= 2026-01-01];
}
public List<Case> openedSince() {
// FLAGGED: SOQL query filters on a hardcoded date literal
return [SELECT Id FROM Case WHERE CreatedDate > 2026-01-01T00:00:00Z];
}
public List<Opportunity> closedRecently() {
return [SELECT Id, Name FROM Opportunity WHERE CloseDate = LAST_N_DAYS:30];
}
public List<Case> openedAfter(Datetime since) {
return [SELECT Id FROM Case WHERE CreatedDate > :since];
}
}Remediation
Use a relative date literal where the window is relative - LAST_N_DAYS:30, THIS_MONTH, LAST_FISCAL_QUARTER - and a bind variable where the caller decides the boundary (WHERE CreatedDate > :since). Where a genuinely fixed cutover date is meant, put it in a custom setting or custom metadata so it can be changed without a deployment.