fix(feature_flags): handle same-hour midnight rollover and reject malformed HH:MM

[dreamorosi]

Issue number: closes #8423

Summary

Changes

SCHEDULE_BETWEEN_TIME_RANGE now treats any range whose end is earlier than its start on the clock as crossing midnight, and schema validation only accepts values that are exactly HH:MM.

Rollover was decided by comparing hours alone, so a range like START: "23:30", END: "23:00" (equal hours) fell into the same-day branch start <= now <= end, which can never hold. The comparator now compares minutes since midnight.

Separately, TIME_RANGE_PATTERN was unanchored and used with re.match, so "10:00abc" validated and then raised inside int() at evaluation time, where _match_by_action swallows the error and returns False. The pattern is now anchored (^(?:2[0-3]|[01]\d):[0-5]\d$) so the misconfiguration surfaces as a SchemaValidationError.

Regression tests cover a same-hour overnight range at a time inside it (10:00) and at the only uncovered gap (23:15), plus malformed START/END strings with trailing or leading garbage and extra digits. All four new cases fail against the previous code.

This also aligns evaluation with the TypeScript port in aws-powertools/powertools-lambda-typescript#5614.

User experience

Before

• A rule with {"START": "23:30", "END": "23:00"} silently never matched, at any time of day.
• A rule with {"START": "10:00abc", "END": "12:00"} passed SchemaValidator().validate() and then silently evaluated to False.

After

• {"START": "23:30", "END": "23:00"} matches from 23:30 through 23:00 the next day, i.e. everything except 23:00-23:30.
• {"START": "10:00abc", "END": "12:00"} raises SchemaValidationError: 'START' and 'END' must be a valid time format, time_format=%H:%M, rule=... at validation time.

Existing valid HH:MM configurations are unaffected.

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Disclaimer: We value your time and bandwidth. As such, any pull requests created on non-triaged issues might not be successful.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.65%. Comparing base (23017e0) to head (f96f47b).

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #8428   +/-   ##
========================================
  Coverage    96.65%   96.65%           
========================================
  Files          296      296           
  Lines        14896    14898    +2     
  Branches      1265     1265           
========================================
+ Hits         14398    14400    +2     
  Misses         363      363           
  Partials       135      135           

☔ View full report in Codecov by Harness.
📢 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.

[leandrodamascena]

I'll review this by tomorrow.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[leandrodamascena]

Thanks Andrea, this looks good. I pushed a small follow-up to use fullmatch(), since Python’s $ still accepts a final newline.

Valid HH:MM configurations are not affected. Invalid values are now rejected as expected, and the rollover fix behaves correctly. I’ll merge this.

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request