fix(dav): handle out-of-range datetime values in file search

[Ahnz]

Summary

Some DAV SEARCH requests use very broad datetime bounds for file search. For example, media searches may use a range such as 0001-01-01 to 4001-01-01 to search across all possible media dates.

On 32-bit PHP, those bounds are outside the timestamp range that can be represented as a native integer:

• dates before 1970 are below the representable range
• dates after 2038 are beyond the representable range

When FileSearchBackend::castValue() converts such a datetime with DateTime::getTimestamp(), PHP throws because the resulting timestamp does not fit into a 32-bit integer. PHP 8.2 throws ValueError; PHP 8.3 and newer throw DateRangeError.

transformSearchOperation() then turns the error into:

InvalidArgumentException: Invalid property value for {DAV:}getlastmodified

The whole SEARCH request fails.

Fix

Move DATETIME casting into a small helper and handle datetime values that cannot be represented on the current platform by clamping them to the platform-supported range:

• values below the representable range to 0
• values beyond the platform max to PHP_INT_MAX

This preserves the existing behavior for datetime values that can be represented on the current platform. The added handling only applies when DateTime::getTimestamp() cannot represent the value.

This does not extend the supported date range on 32-bit PHP. It keeps the SEARCH request executable by mapping out-of-range search bounds to the nearest documented 32-bit boundary.

Notes

The fix is generic for DAV datetime search values and is not specific to the iOS client.

Related issues:

• Related server-side issue: [Bug]: Epoch doesn't fit in a PHP integer #35950
• Related client-side symptom: Photos tab empty after iOS app update – SEARCH WebDAV request cancelled (NSURLErrorDomain -999) ios#3888

Testing

• Tested manually on 32-bit PHP with Nextcloud Server 33.0.3.2
• Tested with Nextcloud iOS 33.0.8
• Verified that the Photos/Media tab loads again
• Verified that Invalid property value for {DAV:}getlastmodified no longer appears in nextcloud.log
• Ran php -l apps/dav/lib/Files/FileSearchBackend.php

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes are not required
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable
• Labels added where applicable
• Milestone added for target branch/version

AI

• The content of this PR was partly or fully generated using AI.

[artonge]

Looks good.

Some DAV SEARCH requests use very broad datetime bounds for file search

Do you have examples?

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)

[Ahnz]

Do you have examples?

One public example for broad datetime bounds is in nextcloud/ios#3598, where the iOS media search log contains:

Start searchMedia with lessDate 4001-01-01 00:00:00 +0000, greaterDate 0001-01-01 00:00:00 +0000, limit 300

That is the kind of broad date range I meant. On 32-bit PHP, both sides are outside the representable timestamp range: 0001-01-01 is before 1970 and 4001-01-01 is after 2038.

I also reproduced this locally on a 32-bit Nextcloud setup with the current iOS app. The iOS log showed the media search failing against /remote.php/dav. The server log then showed the backend failure while handling the DAV SEARCH request:

{
  "app": "webdav",
  "method": "SEARCH",
  "url": "/remote.php/dav",
  "message": "Invalid property value for {DAV:}getlastmodified",
  "userAgent": "Mozilla/5.0 (iOS) Nextcloud-iOS/33.0.8",
  "version": "33.0.3.2",
  "exception": {
    "Exception": "InvalidArgumentException",
    "Message": "Invalid property value for {DAV:}getlastmodified",
    "File": "/var/www/nextcloud/apps/dav/lib/Files/FileSearchBackend.php",
    "Previous": {
      "Exception": "ValueError",
      "Message": "Epoch doesn't fit in a PHP integer",
      "File": "/var/www/nextcloud/apps/dav/lib/Files/FileSearchBackend.php"
    }
  }
}

If I am not mistaken, the same code path can also be triggered with a direct DAV SEARCH request on 32-bit PHP by searching {DAV:}getlastmodified with an out-of-range datetime value, like 4001-01-01T00:00:00Z.