[API] Support time filter for list applications

[EmiliaPaz]

Description

List applications have fromDate and toDate parameters that receive an ISO-8601 date (YYYY-MM-DD). This PR updates the date parser to support time stamps, still with the ISO-8601 format.

In order to not break current calls, we need to continue supporting only date parameters. Therefore, we introduce parseIso8601DateToLocalDateTimeInstant(dateString) with three parsing scenarios in order of preference:

1. Full ISO-8601 string with timezone information (e.g., "2023-12-25T10:30:00Z")
2. ISO-8601 date-time without timezone (e.g., "2023-12-25T10:30:00"), converted using the configured local zone
3. ISO-8601 date only (e.g., "2023-12-25"), defaulting to start of day in local timezone

Since we are maintaining existing functionality, this change is not under a feature flag

User-facing documentation will be updated in civiform/docs#559

Checklist

General

Read the full guidelines for PRs here

• Added the correct label (see docs for more info): < feature | enhancement | bug | under-development | dependencies | infrastructure | ignore-for-release | database >
• Assigned to a specific person, civiform/developers, or a more specific round-robin list
• Added an additional reviewer from outside your organization as FYI (if the primary reviewer is in the same organization as you)
• Removed the release notes section if the title is sufficient for the release notes description, or put more details in that section.
• Created unit and/or browser tests which fail without the change (if possible)
• Performed manual testing (Chrome and Firefox if it includes front-end changes)
• Extended the README / documentation, if necessary. For user-facing features, consider updating the user docs. For "under-the-hood" changes or things more relevant to developers, consider updating the dev wiki.
• Ensured PII wasn't added to any new logs, unless it was guarded by isDevOrStaging
• Noted in the PR description which, if any, code in this PR was generated by AI.

Issue(s) this completes

Part of #5483

[EmiliaPaz]

• [API] Support time filter for list applications #10636 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 83.39%. Comparing base (55cdecc) to head (0480d37).
Report is 53 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##               main   #10636   +/-   ##
=========================================
  Coverage     83.38%   83.39%           
- Complexity     4520     4522    +2     
=========================================
  Files           522      522           
  Lines         19973    19980    +7     
  Branches       1301     1301           
=========================================
+ Hits          16655    16662    +7     
  Misses         2816     2816           
  Partials        502      502           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[gwendolyngoetz]

This looks great! I was playing around with it testing different dates. The only two things I can across:

1. calculating the date zoneId (mentioned below)
2. if both the fromDate and toDate are the same down to the millisecond for the record it doesn't match. Example if the submit date of the record (in localtime) is "2025-04-29T15:47:15.687298", and both the fromDate and toDate are that same value you don't get the record. I don't see this being a problem we need to handle, but may be worth noting.

[EmiliaPaz]

2. if both the fromDate and toDate are the same down to the millisecond for the record it doesn't match. Example if the submit date of the record (in localtime) is "2025-04-29T15:47:15.687298", and both the fromDate and toDate are that same value you don't get the record. I don't see this being a problem we need to handle, but may be worth noting.

Great catch. This is because fromDate is on or after and toDate is before. I think we should keep toDate as exclusive since it's the current behavior. We could change the API implementation to be, if fromDate and toDate parse to the same string, return all records that match that exact entry. However, that's dealign with an edge case. I think it's better to document this. If it's an issue for a government, we can consider addressing it. Thoughts?

[gwendolyngoetz]

2. if both the fromDate and toDate are the same down to the millisecond for the record it doesn't match. Example if the submit date of the record (in localtime) is "2025-04-29T15:47:15.687298", and both the fromDate and toDate are that same value you don't get the record. I don't see this being a problem we need to handle, but may be worth noting.

Great catch. This is because fromDate is on or after and toDate is before. I think we should keep toDate as exclusive since it's the current behavior. We could change the API implementation to be, if fromDate and toDate parse to the same string, return all records that match that exact entry. However, that's dealign with an edge case. I think it's better to document this. If it's an issue for a government, we can consider addressing it. Thoughts?

It's only an issue if someone tries to get records at a fraction of a millisecond level. Realistically no one is going to do that. As long as it's clear that fromDate/toDate need to be in the docs we're fine.