Create rule S8129: SOQL queries should not contain hardcoded date literals

rules/S8129/apex/metadata.json

@@ -0,0 +1,27 @@
+{
+  "title": "SOQL queries should not contain hardcoded date literals",
+  "type": "CODE_SMELL",
+  "status": "ready",
+  "remediation": {
+    "func": "Constant/Issue",
+    "constantCost": "5 min"
+  },
+  "tags": [
+    "soql",
+    "salesforce"
+  ],
+  "defaultSeverity": "Blocker",
+  "ruleSpecification": "RSPEC-8129",
+  "sqKey": "S8129",
+  "scope": "Main",
+  "defaultQualityProfiles": [
+    "Sonar way"
+  ],
+  "quickfix": "unknown",
+  "code": {
+    "impacts": {
+      "MAINTAINABILITY": "BLOCKER"
+    },
+    "attribute": "CONVENTIONAL"
+  }
+}

rules/S8129/apex/rule.adoc

@@ -0,0 +1,59 @@
+This rule raises an issue when a SOQL query contains hardcoded date or datetime literals in WHERE clauses instead of using bind variables or dynamic date calculations.
+
+== Why is this an issue?
+
+Hardcoded date literals in SOQL queries create several maintenance and flexibility problems.
+
+When you write dates directly in your queries like `2025-06-01T00:00:00Z`, you're creating code that only works for that specific time period. This approach has significant drawbacks:
+
+**Inflexibility**: The query can only retrieve data for the exact dates you specified. If you need to query different time periods, you must modify the code each time.
+
+**Maintenance burden**: Every time you want to analyze data for a different month, quarter, or year, you need to update the hardcoded values and redeploy your code.
+
+**Testing challenges**: It becomes difficult to test your code with different date ranges or to create comprehensive test scenarios that cover various time periods.
+
+**Business logic coupling**: Your data access logic becomes tightly coupled to specific dates, making it harder to reuse the same query logic for different business scenarios.
+
+SOQL provides powerful mechanisms like bind variables and built-in date functions that make queries dynamic and adaptable. Using these features keeps your code flexible and maintainable.
+
+=== What is the potential impact?
+
+Hardcoded date literals make code inflexible and increase maintenance overhead. Every time you need to query different time periods, you must modify and redeploy the code. This approach also makes testing more difficult and couples your queries to specific dates rather than business logic.
+
+== How to fix it
+
+Replace hardcoded date literals with bind variables that reference dynamic date calculations or variables. Use Apex Date and DateTime methods to calculate dates dynamically based on current time or business requirements.
+
+=== Code examples
+
+==== Noncompliant code example
+
+[source,apex,diff-id=1,diff-type=noncompliant]
+----
+SELECT UserId, COUNT(Id) loginCount 
+FROM LoginHistory 
+WHERE LoginTime >= 2025-06-01T00:00:00Z AND LoginTime <= 2025-06-30T23:59:59Z // Noncompliant
+GROUP BY UserId
+----
+
+==== Compliant solution
+
+[source,apex,diff-id=1,diff-type=compliant]
+----
+Date startDate = Date.today().toStartOfMonth();
+Date endDate = Date.today();
+SELECT UserId, COUNT(Id) loginCount 
+FROM LoginHistory 
+WHERE LoginTime >= :startDate AND LoginTime <= :endDate 
+GROUP BY UserId
+----
+
+== Resources
+
+=== Documentation
+
+ * SOQL Date Formats and Date Literals - https://developer.salesforce.com/docs/atlas.en-us.soql_sosl.meta/soql_sosl/sforce_api_calls_soql_select_dateformats.htm[Official Salesforce documentation on date formats and literals in SOQL queries]
+
+ * Apex Date and Datetime Methods - https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_methods_system_date.htm[Reference for Apex Date and DateTime class methods for dynamic date calculations]
+
+ * SOQL Bind Variables - https://developer.salesforce.com/docs/atlas.en-us.soql_sosl.meta/soql_sosl/sforce_api_calls_soql_select_variables.htm[Documentation on using bind variables in SOQL queries]

rules/S8129/metadata.json

@@ -0,0 +1,2 @@
+{
+}