Fix DST transition issue causing forced caching of non-cacheable responses

[Copilot]

This PR fixes a critical issue where responses that should not be cached were being cached for approximately one hour during DST (Daylight Saving Time) transitions when PHP is configured with a non-UTC timezone.

Problem

The library uses new \DateTime('-1 seconds') to create expiry timestamps for cache entries that should not be cached (e.g., responses with Cache-Control: no-cache). During DST transitions, specifically when going from summer time to winter time, there's an hour that repeats. PHP's DateTime class with relative time strings can create ambiguous timestamps that resolve to future times instead of past times.

For example, during the Europe/Berlin DST transition on 2024-10-27:

• Both UTC times "2024-10-27 00:00:56" and "2024-10-27 01:00:56" correspond to "2024-10-27 02:00:56" in local time
• new \DateTime('-1 seconds') could resolve to the later occurrence, creating a future timestamp
• This results in a TTL of ~3599 seconds instead of -1, causing unwanted caching

Solution

Replace new \DateTime('-1 seconds') with new \DateTime('@' . (time() - 1)) in two locations within PrivateCacheStrategy.php. The '@' prefix creates a DateTime object from a Unix timestamp, which is always UTC-based and unambiguous.

Changes

• src/Strategy/PrivateCacheStrategy.php: Fixed two instances where relative DateTime creation was replaced with explicit UTC timestamps
• tests/DstTransitionTest.php: Added comprehensive tests to verify the fix works across different timezones and prevents the DST issue

Impact

• ✅ Cache entries marked for immediate expiry now consistently expire immediately
• ✅ No unexpected caching during DST transitions
• ✅ Consistent behavior across all timezones
• ✅ Maintains all existing functionality - this is a surgical fix

The fix ensures RFC 7234 compliance is maintained while preventing the timezone-related edge case that could cause security or correctness issues.

Fixes #194.

[!WARNING]

Firewall rules blocked me from connecting to one or more addresses

I tried to connect to the following addresses, but was blocked by firewall rules:

• https://api.github.com/repos/guzzle/psr7/zipball/c2270caaabe631b3b44c85f99e5a04bbb8060d16
  • Triggering command: /usr/bin/php8.3 -n -c /tmp/iamHi8 /usr/bin/composer install --no-dev (http block)
• https://api.github.com/repos/php-cache/hierarchical-cache/zipball/dedffd0a74f72c1db76e57ce29885836944e27f3
  • Triggering command: /usr/bin/php8.3 -n -c /tmp/qSfBGF /usr/bin/composer install (http block)
• https://api.github.com/repos/php-fig/http-client/zipball/bb5906edc1c324c9a05aa0873d40117941e5fa90
  • Triggering command: /usr/bin/php8.3 -n -c /tmp/iamHi8 /usr/bin/composer install --no-dev (http block)
• https://api.github.com/repos/php-fig/log/zipball/f16e1d5863e37f8d8c2a01719f5b34baa2b714d3
  • Triggering command: /usr/bin/php8.3 -n -c /tmp/qSfBGF /usr/bin/composer install (http block)
• https://api.github.com/repos/symfony/deprecation-contracts/zipball/63afe740e99a13ba87ec199bb07bbdee937a5b62
  • Triggering command: /usr/bin/php8.3 -n -c /tmp/iamHi8 /usr/bin/composer install --no-dev (http block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.